Announcement

Collapse
No announcement yet.

SQLite 3.40 Released With WASM Support For Web Browsers, Recovery Extension

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by uid313 View Post
    The ORM's query planner probably optimize better than most people.
    Isn't query planning carried out by the actual SQL database instead of ORM?

    Comment


    • #12
      Originally posted by uid313 View Post
      Yeah, 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.
      I haven't seen this be the case of "making code portable" actually work. Every database has its own quirks and needs a bit of TLC to work. You can't just expect your code to work flawlessly across multiple databases, especially if you think you can test on SQLite if you run on PG/MySQL or whatever. Stuff will break in subtle and whacky ways. For example foreign key constraints in SQLite are tricky to deal with https://sqlite.org/forum/forumpost/b17fdd0d59 , and the different types.

      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

      Comment


      • #13
        Will there be a zig+amalg+sqlite vs gcc vs lvm vs python on fast clocked epyc vs xeon dance battle ?
        Tune in next week ?

        Comment


        • #14
          Originally posted by uid313 View Post
          SQLite 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.
          The same restrictions apply to any combination of databases and languages and ORM libraries. Databases only have generic types whereas your app code might use whatever custom classes. If you have to convert a database into app code, you already fucked up a long time ago.

          Comment


          • #15
            WASM support sounds interesting.

            Would I be able to access a DB phisically stored on a user disk via a WASM application?

            Is this the intended usage? (or at least, one of the intended usage)

            Comment


            • #16
              Originally posted by NobodyXu View Post

              Isn't query planning carried out by the actual SQL database instead of ORM?
              Yes, 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.

              Comment


              • #17
                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.
                So you want your mappings to be generated automatically from the schema.
                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


                • #18
                  Originally posted by patrick1946 View Post
                  Yes, 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.
                  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.

                  Comment


                  • #19
                    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.
                    It 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.

                    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


                    • #20
                      Originally posted by patrick1946 View Post
                      It 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.
                      Well I'm not that familiar with sqlite, can you elaborate on that or points me to where I can read about this?

                      Comment

                      Working...
                      X