Yes, and that’s an architectural choice you’re making.
Instead of using all the consistencies provided in the database process - including types, but also date/time, constraints, transactions, triggers etc. you are exiting the system and losing all guarantees.
You can write raw sql and use the "describe" clause in script, and then generate code with the result. This gives full db-backend-frontend type safety with raw sql queries
Only backend to database. This is talking about typesafe from database - backend - frontend.
Yes, and that’s an architectural choice you’re making.
Instead of using all the consistencies provided in the database process - including types, but also date/time, constraints, transactions, triggers etc. you are exiting the system and losing all guarantees.
This system also doesn’t solve that problem.
You can write raw sql and use the "describe" clause in script, and then generate code with the result. This gives full db-backend-frontend type safety with raw sql queries
They might mean static typing in queries.
Which end? This moves one end to reach frontend code
Isn’t sql weakly typed? Or does this depend on the engine?
SQLite is the only one I know of that doesn’t enforce types by default, but I don’t know what the SQL spec requires.
No it is strongly typed, there is no accident that all PL extensions to the base query language have such a Ada/Pascal similarity.
Additional DML has plenty of options to enforce rules that keep data consistency.
While they make the life harder to delete/update/insert items in specific sequences, they can save the day on bad queries.
What happens if a query compares a string to a number?
1 reply →