2 ms·

How practical is sqlite for anything more than single user applications?

by hoodoof 14y ago

kbenson 14y ago
Probably not very. That said, for single user applications (such as ios/android apps) or rapid prototyping, they may be very practical. Then again, prototyping is only as useful as it is easy to trade out for the eventual solution, and if it has a different query syntax than what you replace it with, you were probably better off with the pain to set that up in the first place. I could see a SQLite-alike JSON database doing really well in the phone app space. Especially for those using a framework like phonegap that allows you write in javascript. In fact, I think this is obvious enough that there probably exist solutions for this, and I'm just not knowledgeable enough in the subject to know of them.
- jaredsohn 14y ago
  >prototyping is only as useful as it is easy to trade out for the eventual solution It is also useful if you find out from prototyping that the project is not viable. Also, in general, if you need to iterate a lot using something that iterates faster at the prototype stage would have extra benefit. (Although in this particular case I think using SQLite only saves you initial configuration time.)
  - kbenson 14y ago
    > It is also useful if you find out from prototyping that the project is not viable True. I considered this when writing the reply, but decided to not obfuscate my point. It's good that you brought it up and it got addressed though. :) > Also, in general, if you need to iterate a lot using something that iterates faster at the prototype stage would have extra benefit I'm not sure it's worth it if it's significantly different than the eventual solution will be (and you're fairly certain it won't map). That can be as simple (and horrible) as prototyping against NoSQL when you know production will be SQL (or vice-versa), or as subtle as using a feature present in one RDBMS which is buggy or non functional in a different RDBMS, which is the one that will be used in production. The longer you code using the prototyping data store, the more likely you are to inadvertently use a feature which will cause you problems later in production. Now, SQL is fairly standardized, and SQLite as a prototyping tool is unlikely to cause a problem later if the production environment is a full RDBMS, but you may end up not using a few features only available in the full RDBMS that could have lead to a cleaner and/or more performant solution.

How practical is sqlite for anything more than single user applications?

by hoodoof 14y ago

How practical is sqlite for anything more than single user applications?

Probably not very. That said, for single user applications (such as ios/android apps) or rapid prototyping, they may be very practical. Then again, prototyping is only as useful as it is easy to trade out for the eventual solution, and if it has a different query syntax than what you replace it with, you were probably better off with the pain to set that up in the first place. I could see a SQLite-alike JSON database doing really well in the phone app space. Especially for those using a framework like phonegap that allows you write in javascript. In fact, I think this is obvious enough that there probably exist solutions for this, and I'm just not knowledgeable enough in the subject to know of them.

jaredsohn 14y ago
>prototyping is only as useful as it is easy to trade out for the eventual solution It is also useful if you find out from prototyping that the project is not viable. Also, in general, if you need to iterate a lot using something that iterates faster at the prototype stage would have extra benefit. (Although in this particular case I think using SQLite only saves you initial configuration time.)
- kbenson 14y ago
  > It is also useful if you find out from prototyping that the project is not viable True. I considered this when writing the reply, but decided to not obfuscate my point. It's good that you brought it up and it got addressed though. :) > Also, in general, if you need to iterate a lot using something that iterates faster at the prototype stage would have extra benefit I'm not sure it's worth it if it's significantly different than the eventual solution will be (and you're fairly certain it won't map). That can be as simple (and horrible) as prototyping against NoSQL when you know production will be SQL (or vice-versa), or as subtle as using a feature present in one RDBMS which is buggy or non functional in a different RDBMS, which is the one that will be used in production. The longer you code using the prototyping data store, the more likely you are to inadvertently use a feature which will cause you problems later in production. Now, SQL is fairly standardized, and SQLite as a prototyping tool is unlikely to cause a problem later if the production environment is a full RDBMS, but you may end up not using a few features only available in the full RDBMS that could have lead to a cleaner and/or more performant solution.