3 ms·

100% agree with this post and it's important to understand where/when schema in the code makes more sense than schema in the db. If the DB is determining the s

100% agree with this post and it's important to understand where/when schema in the code makes more sense than schema in the db. If the DB is determining the schema and your code just mirrors it, you will inevitably do things like triggers, stored procedures, etc. that essentially put application code inside the DB. This makes testing and maintenance of such things all but impossible, even if it does make the DB queries fast. At the same time, your application still needs to mirror the schema of the DB or things will break. "Schemaless" (query schemas) isn't better per se, but having the mindset of putting the schema in the code means you can write tests to ensure the schema over time. Depending on your perspective, one might be better than the other, but as they say "knowing is half the battle"

joe_the_user 13y ago
If the DB is determining the schema and your code just mirrors it, you will inevitably do things like triggers, stored procedures, etc. that essentially put application code inside the DB. This makes testing and maintenance of such things all but impossible, even if it does make the DB queries fast. I don't believe this is necessarily true. I think it depends on the structure of the enterprise. The traditional relational database seems to center on what could be called the "traditional large enterprise". This large enterprise tends to have many projects sharing the same static data and here a single store for that data makes sense and that store can and should have a standard interface, which can be embodied as stored procedures if necessary and would have to be well-defined enough that individual applications can deal with it. That's the "traditional large enterprise". Today, however, we have large companies where single application has become the essence of the company (Google, Facebook, etc)and the one-datastore, multiple-applications model no longer makes sense and it does make sense to move more data manipulation the application level. Still, when making pronouncements about what works best, I think context is important.
- dragonwriter 13y ago
  > Today, however, we have large companies where single application has become the essence of the company (Google, Facebook, etc)and the one-datastore, multiple-applications model no longer makes sense Which "one application" is the essence of Google?
  - joe_the_user 13y ago
    Whatever, say, Google-a-few-year-back then.
    - dragonwriter 13y ago
      Which just illustrates that while comparatively young companies may all be all about one application, its not exactly unusual even for a company that starts out that way to rapidly grow into one providing a large array of applications with overlapping use of data. While there are reasons that running all those applications for, say, Google on a shared RDBMS backend isn't the right answer, the reason isn't that Google has a single application that uses all its data and so doesn't have to worry about coordination between different applications using the same data.
  - coldtea 13y ago
    All of them. Google is mainly a bunch of "one applications". Maps is maps, Search is search, YouTube is YouTube, GMail is Gmail etc. Those are not apps providing different views of the same data, in the way the parent describer enterprise apps.
dragonwriter 13y ago
> If the DB is determining the schema and your code just mirrors it, you will inevitably do things like triggers, stored procedures, etc. that essentially put application code inside the DB. This makes testing and maintenance of such things all but impossible If testing and maintenance of database objects (tables and other relations, as well as procedural code in triggers, SPs, etc.) is "all but impossible", the problem is with your DB maintenance policies and practices, not with where you are putting code. It may be the case that lots of places have bad database maintenance practices (just as lots of places have bad maintenance practices for non-DB software), and it may be that in those environments, when you have a limited scope of influence, routing around those bad practices is the best solution. But it is a mistake to present that as a general solution.
camus 13y ago
> This makes testing and maintenance of such things all but impossible Developers have been maintaining such apps for decades without any problem. And everything is testable , even a stocked procedure. If you dont care about data integrity, then make your application responsible for your schema...Some do care. Non-rel databases guarantee 0 data integrity, with very little performance gain over relational-databases. Finally most frameworks allow developpers to generate the db schema during development without writing a single query. with all the cache layers like redis and other goodies , there is little to no reason to use non-rel databases.
- lttlrck 13y ago
  "Non-rel databases guarantee 0 data integrity, with very little performance gain over relational-databases." guarantee ZERO data integrity?
- tracker1 13y ago
  A given RDBMS doesn't guarantee any data integrity. The integrity is a bit of a lie. I've seen plenty of real world databases with software created by idiots where a DateTime field was defined as a VARCHAR. Or fields that should have been a VARCHAR created as CHAR, then bugs happen with the strings aren't auto-trimmed. IMHO the database these days SHOULD be fairly agnostic. Also normalization, which is the core of your so called integrity actually REDUCES performance. At my last job, our main VIEW into the data took over 28 join operations for some highly normalized data (much of which had to overcome some bad data in the db). We setup a MongoDB database for searching against, as well as being able to pull up a single record without dozens of join operations, and it was a LOT faster, against real-time data... the search that was replaced was a batch process that recreated a single table every half hour. In this case MongoDB was a much better fit. Sorry, but SQL databases don't guarantee any data integrity either. It's up to the developers that implement those schemas... and the fact is, for most of them, they are better off doing that in their primary application code. Also, if you are using an ORM tool to "generate" your schema from code, then what advantage does said schema's "integrity" give you?

joe_the_user 13y ago

If the DB is determining the schema and your code just mirrors it, you will inevitably do things like triggers, stored procedures, etc. that essentially put application code inside the DB. This makes testing and maintenance of such things all but impossible, even if it does make the DB queries fast. I don't believe this is necessarily true. I think it depends on the structure of the enterprise. The traditional relational database seems to center on what could be called the "traditional large enterprise". This large enterprise tends to have many projects sharing the same static data and here a single store for that data makes sense and that store can and should have a standard interface, which can be embodied as stored procedures if necessary and would have to be well-defined enough that individual applications can deal with it. That's the "traditional large enterprise". Today, however, we have large companies where single application has become the essence of the company (Google, Facebook, etc)and the one-datastore, multiple-applications model no longer makes sense and it does make sense to move more data manipulation the application level. Still, when making pronouncements about what works best, I think context is important.

dragonwriter 13y ago
> Today, however, we have large companies where single application has become the essence of the company (Google, Facebook, etc)and the one-datastore, multiple-applications model no longer makes sense Which "one application" is the essence of Google?
- joe_the_user 13y ago
  Whatever, say, Google-a-few-year-back then.
  - dragonwriter 13y ago
    Which just illustrates that while comparatively young companies may all be all about one application, its not exactly unusual even for a company that starts out that way to rapidly grow into one providing a large array of applications with overlapping use of data. While there are reasons that running all those applications for, say, Google on a shared RDBMS backend isn't the right answer, the reason isn't that Google has a single application that uses all its data and so doesn't have to worry about coordination between different applications using the same data.
- coldtea 13y ago
  All of them. Google is mainly a bunch of "one applications". Maps is maps, Search is search, YouTube is YouTube, GMail is Gmail etc. Those are not apps providing different views of the same data, in the way the parent describer enterprise apps.

dragonwriter 13y ago

> If the DB is determining the schema and your code just mirrors it, you will inevitably do things like triggers, stored procedures, etc. that essentially put application code inside the DB. This makes testing and maintenance of such things all but impossible If testing and maintenance of database objects (tables and other relations, as well as procedural code in triggers, SPs, etc.) is "all but impossible", the problem is with your DB maintenance policies and practices, not with where you are putting code. It may be the case that lots of places have bad database maintenance practices (just as lots of places have bad maintenance practices for non-DB software), and it may be that in those environments, when you have a limited scope of influence, routing around those bad practices is the best solution. But it is a mistake to present that as a general solution.

camus 13y ago

> This makes testing and maintenance of such things all but impossible Developers have been maintaining such apps for decades without any problem. And everything is testable , even a stocked procedure. If you dont care about data integrity, then make your application responsible for your schema...Some do care. Non-rel databases guarantee 0 data integrity, with very little performance gain over relational-databases. Finally most frameworks allow developpers to generate the db schema during development without writing a single query. with all the cache layers like redis and other goodies , there is little to no reason to use non-rel databases.

lttlrck 13y ago
"Non-rel databases guarantee 0 data integrity, with very little performance gain over relational-databases." guarantee ZERO data integrity?
tracker1 13y ago
A given RDBMS doesn't guarantee any data integrity. The integrity is a bit of a lie. I've seen plenty of real world databases with software created by idiots where a DateTime field was defined as a VARCHAR. Or fields that should have been a VARCHAR created as CHAR, then bugs happen with the strings aren't auto-trimmed. IMHO the database these days SHOULD be fairly agnostic. Also normalization, which is the core of your so called integrity actually REDUCES performance. At my last job, our main VIEW into the data took over 28 join operations for some highly normalized data (much of which had to overcome some bad data in the db). We setup a MongoDB database for searching against, as well as being able to pull up a single record without dozens of join operations, and it was a LOT faster, against real-time data... the search that was replaced was a batch process that recreated a single table every half hour. In this case MongoDB was a much better fit. Sorry, but SQL databases don't guarantee any data integrity either. It's up to the developers that implement those schemas... and the fact is, for most of them, they are better off doing that in their primary application code. Also, if you are using an ORM tool to "generate" your schema from code, then what advantage does said schema's "integrity" give you?