Jon is a self-taught programmer, started in video games but now does web development. He follows principles, argues for scientific software development, and does not like writing in the 3rd person.
It is now possible to move the integrity checks to the API layer if it is common to all applications but DO NOT leave it up to the front end devs to encapsulate the business rules.
Fully agree here. I didn't even realize I was implying anything but keeping the API layer responsible for business requirements.
As for the rest, I really do like your clear angle and rebuttal. I think fundamentally I oppose the sentence "my database", because I want to break down silos and optimize for feeling ownership of the product, not any of the subsystems. That's my positive spin on my angle, but you could just as well say I'm an API-centric chauvinist who wants the world to revolve around the API and you wouldn't be entirely wrong.
Anyway,
I think we're fundamentally pitted against each other because I kinda want developers to not care about CHARS, VARCHARS, etc. To me those are details that distracts the code from being focused on just modeling the business requirements.
Thankfully its fine we're "pitted against each other" because I love hearing your angle, it's so different from mine and I can only learn from that. It err… might be best we don't work on the same project 😅, but thank you for taking the time to elucidate your angle.
Its not a war, at the end of the day we are all on the same team trying to provide value to the business. My point is that constraints in the RDBMs database are there for a reason; it prevents rogue application code from destroying fundamental business data. If you are not going to use them you might as well use a document database or flat text files. Just like your C# / java / python classes are trying to model the real world, so is the relational database. As it is the last line of defense, it HAS to be correct. If front end and middleware developers are creating workarounds then this is an indication that the database model is out of date.
I once did a lignting talk at our local geek-meet about how code-first ORMs (specifically Entity Framework, but the same applies to Eloquent) can help you to rapidly prototype the application and supporting database, but the data types it uses are not optimised (unless you use Fluent, in which case you might as well use DDL in Management Studio) Using a repository layer and Active Record pattern can help but it is still no substitue for a properly configured database.
Some of the crap I have seen:
Dates stored in datetime fields.
Date and time stored in SEPARATE datetime fields.
dates stored as strings
Y/N held in VARCHAR(1000)
Phone number 1, Phone number 2, Phone number 3 ....
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Fully agree here. I didn't even realize I was implying anything but keeping the API layer responsible for business requirements.
As for the rest, I really do like your clear angle and rebuttal. I think fundamentally I oppose the sentence "my database", because I want to break down silos and optimize for feeling ownership of the product, not any of the subsystems. That's my positive spin on my angle, but you could just as well say I'm an API-centric chauvinist who wants the world to revolve around the API and you wouldn't be entirely wrong.
Anyway,
I think we're fundamentally pitted against each other because I kinda want developers to not care about CHARS, VARCHARS, etc. To me those are details that distracts the code from being focused on just modeling the business requirements.
Thankfully its fine we're "pitted against each other" because I love hearing your angle, it's so different from mine and I can only learn from that. It err… might be best we don't work on the same project 😅, but thank you for taking the time to elucidate your angle.
Its not a war, at the end of the day we are all on the same team trying to provide value to the business. My point is that constraints in the RDBMs database are there for a reason; it prevents rogue application code from destroying fundamental business data. If you are not going to use them you might as well use a document database or flat text files. Just like your C# / java / python classes are trying to model the real world, so is the relational database. As it is the last line of defense, it HAS to be correct. If front end and middleware developers are creating workarounds then this is an indication that the database model is out of date.
I once did a lignting talk at our local geek-meet about how code-first ORMs (specifically Entity Framework, but the same applies to Eloquent) can help you to rapidly prototype the application and supporting database, but the data types it uses are not optimised (unless you use Fluent, in which case you might as well use DDL in Management Studio) Using a repository layer and Active Record pattern can help but it is still no substitue for a properly configured database.
Some of the crap I have seen:
Dates stored in datetime fields.
Date and time stored in SEPARATE datetime fields.
dates stored as strings
Y/N held in VARCHAR(1000)
Phone number 1, Phone number 2, Phone number 3 ....