4 ms·

I have never used a graph database but I can say there is one truth in the article: I find I have to stop and structure my app around the tables I need, and hav

I have never used a graph database but I can say there is one truth in the article: I find I have to stop and structure my app around the tables I need, and have had to stop and reorganize my code and data to fit a proper table structure when I realize my existing table structure doesn't make sense or hits the database too hard. I have no idea if graph databases are the answer to that problem, but I do get tired of building code to work around my database and it's oddities rather than my data just fitting nicely into the code. The number of migrations I've built just to change something because the database needed it built differently rather than my application needing it is silly.

hitpointdrew 6y ago
You probably just want any NO-SQL database then, not necessarily a Graph DB. MongoDB or Elasticsearch should fit your needs. The thing that is great about relational databases is data integrity, the thing that sucks about relational databases is data integrity. NO-SQL is fantastic, but if you want you data to adhere to ACID then there is simply no substitute for a relational database.
- LukeEF 6y ago
  Some graph databases, like TerminusDB and others, give strong ACID guarantees and enforce data integrity - you can have the best of all worlds
nawgszy 6y ago
Could you say more about some of these times? I'm curious what it means in more concrete terms. I only say this because I am a UI engineer who has been in some scrappy situations, so obviously I don't get to change the data model. What kind of structures do you find that "hit the database too hard" or otherwise invoke performance penalties?
- freehunter 6y ago
  When I say "hit the database too hard" what I actually mean is making too many calls to the database. If I have to make three or four calls just to get all the data I need, performance is going to take a hit. And databases are often the worst-performing part of the tech stack, so you have to craft your queries around the performance bottleneck of the database. So you have to balance your table structure around getting the data you need in as few calls as possible while also only returning exactly as much data as you need and no more. Because pulling extra data out puts more load on the database and shipping more data across the network is slower. In general, relational databases (RBDs) like Postgres or MySQL are great for making sure your data follows the correct structure (this field is a string, this is an integer, this field in table1 has to be the same as this field in table2, etc) but make it hard to make changes to the data structure later. What happens if that int should actually be a float? Now you have to write a migration that makes fundamental changes to the structure of the data and hope there are no negative side effects. Someone else mentioned NoSQL databases, which offer a lot more flexibility at the cost of the data integrity that RDBs enforce. If you suddenly want to store a float instead of an int, go ahead. No one is stopping you, you just need to make sure your code is updated to handle the possibility of getting back an int or float (or coerce the value to the right type and pray). Basically a database is integral to almost all applications but they're complex monsters with their own structure and rules and performance implications. If you're building an application you really have to know the data structure of the final product before you even _start_ configuring the database.
  - balfirevic 6y ago
    > but make it hard to make changes to the data structure later. What happens if that int should actually be a float? Now you have to write a migration that makes fundamental changes to the structure of the data and hope there are no negative side effects. This is often stated, but it's not true. RDBMS make it easier to make changes to the data structure precisely because you only have to write migration and after that you are guaranteed to only ever get the data out of database in the new format. Which means your application code doesn't accumulate the cruft of dealing with two possible database data formats.
    - 6y ago

hitpointdrew 6y ago

You probably just want any NO-SQL database then, not necessarily a Graph DB. MongoDB or Elasticsearch should fit your needs. The thing that is great about relational databases is data integrity, the thing that sucks about relational databases is data integrity. NO-SQL is fantastic, but if you want you data to adhere to ACID then there is simply no substitute for a relational database.

LukeEF 6y ago
Some graph databases, like TerminusDB and others, give strong ACID guarantees and enforce data integrity - you can have the best of all worlds

nawgszy 6y ago

Could you say more about some of these times? I'm curious what it means in more concrete terms. I only say this because I am a UI engineer who has been in some scrappy situations, so obviously I don't get to change the data model. What kind of structures do you find that "hit the database too hard" or otherwise invoke performance penalties?

freehunter 6y ago
When I say "hit the database too hard" what I actually mean is making too many calls to the database. If I have to make three or four calls just to get all the data I need, performance is going to take a hit. And databases are often the worst-performing part of the tech stack, so you have to craft your queries around the performance bottleneck of the database. So you have to balance your table structure around getting the data you need in as few calls as possible while also only returning exactly as much data as you need and no more. Because pulling extra data out puts more load on the database and shipping more data across the network is slower. In general, relational databases (RBDs) like Postgres or MySQL are great for making sure your data follows the correct structure (this field is a string, this is an integer, this field in table1 has to be the same as this field in table2, etc) but make it hard to make changes to the data structure later. What happens if that int should actually be a float? Now you have to write a migration that makes fundamental changes to the structure of the data and hope there are no negative side effects. Someone else mentioned NoSQL databases, which offer a lot more flexibility at the cost of the data integrity that RDBs enforce. If you suddenly want to store a float instead of an int, go ahead. No one is stopping you, you just need to make sure your code is updated to handle the possibility of getting back an int or float (or coerce the value to the right type and pray). Basically a database is integral to almost all applications but they're complex monsters with their own structure and rules and performance implications. If you're building an application you really have to know the data structure of the final product before you even _start_ configuring the database.
- balfirevic 6y ago
  > but make it hard to make changes to the data structure later. What happens if that int should actually be a float? Now you have to write a migration that makes fundamental changes to the structure of the data and hope there are no negative side effects. This is often stated, but it's not true. RDBMS make it easier to make changes to the data structure precisely because you only have to write migration and after that you are guaranteed to only ever get the data out of database in the new format. Which means your application code doesn't accumulate the cruft of dealing with two possible database data formats.
  - 6y ago