Originally posted by uid313
View Post
Announcement
Collapse
No announcement yet.
SQLite 3.40 Released With WASM Support For Web Browsers, Recovery Extension
Collapse
X
-
Originally posted by uid313 View PostYeah, I do dislike SQL. With SQL you are writing database-specific SQL since every database server has slightly different SQL language so with a ORM you abstract that way and make the code more portable.
The ORM's query planner probably optimize better than most people.
With a ORM you can have the compiler ensure that the references columns and tables actually exist, everything is strongly typed.
I love ORMs and am glad I don't have to deal with raw SQL too often.
Having an ORM infront and not caring about SQL just makes for incredibly bad queries most of the time, leading to pain down the road. You still should tweak and analyse to make your queries fly, databases now adays are great . SQL isn't as bad as it use to be and "modern SQL" is pretty great.
I love SQLite, Postgres btw (and ORMs) so don't take this as a flame
- Likes 4
Comment
-
Originally posted by uid313 View PostSQLite have very few data types, it has like TEXT, INTEGER, and REAL. It doesn't have boolean or datetime, so when you reverse engineer a database (turn an existing database into code for use by a ORM) it cannot generate classes that use datatypes available in the programming language so you end up with shitty generated classes where dates are string and booleans are integers.
- Likes 4
Comment
-
Originally posted by NobodyXu View Post
Isn't query planning carried out by the actual SQL database instead of ORM?
Comment
-
Originally posted by uid313 View Post
The ORM can't figure out the data types to use because SQLite hasn't dedicated data types for many common data types such as char, bool and datetime.
I get it, but making a few adjustments when working with SQLite doesn't seem a major drawback, considering that you should check the generated classes anyway...
Comment
-
Originally posted by patrick1946 View PostYes, it is but maybe he means how the query look. Especially Sqlite is very sensitive too it. But my experience with complains about Sqlite is that people had no deep understanding about it.
I took a SQL internal classes and different ways of writing the same query combined with indexes can give much better performance.
I guess the query planned/optimizer of sqlite is so simple that it is very sensitive to it?
I haven't looked at it, but since it has put a lot emphasis on size and the entire source code can be grouped into one .c to distribute, I guess it just isn't suitable for very complex usecases.
Comment
-
Originally posted by NobodyXu View Post
The query itself indeed is very important.
I took a SQL internal classes and different ways of writing the same query combined with indexes can give much better performance.
I guess the query planned/optimizer of sqlite is so simple that it is very sensitive to it?
I haven't looked at it, but since it has put a lot emphasis on size and the entire source code can be grouped into one .c to distribute, I guess it just isn't suitable for very complex usecases.
Adding one layer of abstraction normally makes it not faster. Sql is a wonderful language to organize data but it's a complete different paradigm to pragamming languages like Python or C++.
Comment
-
Originally posted by patrick1946 View PostIt has to be simple to be fast. If you know Sqlite very well it will be very fast but if arrange your data in a suboptimal way, generate wrong indices or write statements which don't use this indices it will be slow.
Comment
Comment