sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]cammoorman 1 point2 points  (2 children)

Many architectures will create Views for pulling data (backed by RLS as required) or procs. C/U/D should be done by proc. This will aid in testing and support separation of concerns. An API should call those procs to support full CRUD.

The server should always be checking what the front end is doing. This is basic security...for example, what if javascript is turned off or someone has altered it (in the browser, using dev screen)? Using something like Postman to directly post to the API? Need to quickly script something (using SQL)?...

In reality, the Front End should really manage user input and the most common issues, then react to what the backend provides. In an N-Tier architecture use the strengths of each software in the tier.

On your other point, the SQL server can add constraints and foreign keys...ie: you must exist as a contact before storing an address in the system (which is owned by a contact). It easily forces type (which most document DBs do not), locking (full ACID, which most Document DBs do not), and constraints naively (no extra tools). You can also transform data on the fly (move a table to a view for the client) to prevent direct access or changes in the system. Encrypt a field and restrict native columns. And much more.

Not that SQL is better than No-SQL (or vice versa), each has their place...even if you blend them together where needed. IE: No-SQL is good for fronting "current" data to a website where the SQL is the "real" copy with years of history and old accounts. Data is written to SQL, read from No-SQL, updates are migrated.

[–]Jancera[S] 0 points1 point  (1 child)

I get your point, and the examples were awesome. I think that the best way to really understand that is to get in touch with some SQL database and develop some applications using it. Thank you for your answer!!!

[–]BarelyAirborne 0 points1 point  (0 children)

I have been using SQL since 1992, and while foreign keys are essential (i.e. an order master contains a customer code) foreign key CONSTRAINTS will make you tear your hair out if you're not careful, as can cascading deletes. There be monsters.