3 ms·

SQL is really good at projecting & selecting simple data. My rule of thumb has been to use it first for any per projects and but as soon I need more than one ta

by plet 9y ago

SQL is really good at projecting & selecting simple data. My rule of thumb has been to use it first for any per projects and but as soon I need more than one table, think deeper about the data and switch to NoSQL if I need to represent complex data structures or have document storage needs. Its still amazing how far you can go with a single table and few tweaks to a postgres instance.

collyw 9y ago
Sounds like you need to learn how to design a database. Seriously, do you find more than 1 table complex?
- plet 9y ago
  That's odd. I don't recall saying more than 1 table is complex. For me, it's just a good time to think more about what kind of database to use, esp for pet projects.
  - collyw 9y ago
    The wording of your comment makes it easy to interpret it that way.
noja 9y ago
As soon as you have more than one table you switch to NoSQL? Did you meant to write it that way round?
- plet 9y ago
  > As soon as you have more than one table you switch to NoSQL? Nope. Just start thinking a bit more if I need to continue using RDMS or switch to NoSQL now. I can when the time is right for the project. It varies for projects. While learning phoenix (elixir) I stuck with postgres because the tutorials were easier to follow. While creating a fancy blog engine I switched to Mongo
alunchbox 9y ago
Haven't seen a reason to use any type of NoSQL aside from a cache layer. Most Modern RDBMS have Json support if you still want to use a document approach for specific cases but overall Postgres and SQL Server are able to perform equally if not better then most recent NoSQL implementations (unless it's a really specific one off use case for reading) just look at the nightmare MongoDB has created in most startups a year later.
- mysterydip 9y ago
  The SQLite site says it better than I could: https://sqlite.org/whentouse.html https://sqlite.org/whentouse.html Personally I use NoSQL options for the "replacement of ad-hoc disk files" they mention on that page. Like many of the comments here, anything more advanced than that and I'm using a relational database.
- scarface74 9y ago
  I fell in love with Mongo when I first started using it 6 months ago - the whole NoSql thing appealed to me. Then I fell in love with Sql Server 2016's JSON support - the best of both worlds.
- plet 9y ago
  For me, NoSQL works great when the structure of the data is unclear but you have a fixed identifier that you can key off. SQL when the structure is known and juggling multi-table transactions is not a big PITA. I'm not sure about the mongoDB nightmare, for me its done everything as the documentation claims it'll do.
  - atomical 9y ago
    If the structure of the data changes why wouldn't you modify the schema? Could you give an example of what you are talking about?
  - deleted 9y ago
    [deleted]
danso 9y ago
That's funny, the main reason I cite for going from spreadsheets -- which are powerful enough with pivot tables and VLOOKUP -- to SQL is the ability to use JOIN statements in the latter, i.e. when you need to work with data from multiple tables. Most production SQL databases involve multiple tables, not as a legacy hack but by deliberate design.

by plet 9y ago

collyw 9y ago

Sounds like you need to learn how to design a database. Seriously, do you find more than 1 table complex?

plet 9y ago
That's odd. I don't recall saying more than 1 table is complex. For me, it's just a good time to think more about what kind of database to use, esp for pet projects.
- collyw 9y ago
  The wording of your comment makes it easy to interpret it that way.

noja 9y ago

As soon as you have more than one table you switch to NoSQL? Did you meant to write it that way round?

plet 9y ago
> As soon as you have more than one table you switch to NoSQL? Nope. Just start thinking a bit more if I need to continue using RDMS or switch to NoSQL now. I can when the time is right for the project. It varies for projects. While learning phoenix (elixir) I stuck with postgres because the tutorials were easier to follow. While creating a fancy blog engine I switched to Mongo

alunchbox 9y ago

Haven't seen a reason to use any type of NoSQL aside from a cache layer. Most Modern RDBMS have Json support if you still want to use a document approach for specific cases but overall Postgres and SQL Server are able to perform equally if not better then most recent NoSQL implementations (unless it's a really specific one off use case for reading) just look at the nightmare MongoDB has created in most startups a year later.

mysterydip 9y ago
The SQLite site says it better than I could: https://sqlite.org/whentouse.html https://sqlite.org/whentouse.html Personally I use NoSQL options for the "replacement of ad-hoc disk files" they mention on that page. Like many of the comments here, anything more advanced than that and I'm using a relational database.
scarface74 9y ago
I fell in love with Mongo when I first started using it 6 months ago - the whole NoSql thing appealed to me. Then I fell in love with Sql Server 2016's JSON support - the best of both worlds.
plet 9y ago
For me, NoSQL works great when the structure of the data is unclear but you have a fixed identifier that you can key off. SQL when the structure is known and juggling multi-table transactions is not a big PITA. I'm not sure about the mongoDB nightmare, for me its done everything as the documentation claims it'll do.
- atomical 9y ago
  If the structure of the data changes why wouldn't you modify the schema? Could you give an example of what you are talking about?
- deleted 9y ago
  [deleted]

danso 9y ago

That's funny, the main reason I cite for going from spreadsheets -- which are powerful enough with pivot tables and VLOOKUP -- to SQL is the ability to use JOIN statements in the latter, i.e. when you need to work with data from multiple tables. Most production SQL databases involve multiple tables, not as a legacy hack but by deliberate design.