5 ms·

I'm not sure about your point on schemas. When using relational database you must have your schema in two places: 1. database and 2. ORM - the second one is eno

by dotborg 14y ago

I'm not sure about your point on schemas. When using relational database you must have your schema in two places: 1. database and 2. ORM - the second one is enough to avoid most of problems. What's the point of having schema in database then?

pielud 14y ago
1. Your ORM can derive it's schema from the database's. 2. I think the main point of the post was that you can run ad-hoc SQL queries no matter how much you've denormalized. You can't necessarily do that with a NoSQL database.
- camus 14y ago
  Yet you are still using schemas in 2 places : not DRY , SQL just doesnt fit OOP design. Most of languages today have strong functional capabilities , that makes SQL obsolete , they have functions , event systems , RDBMS exist because people use to query those systems directly , does your users log into your database directly ? no they connect your database through middleware, that's where the job should be done.
  - ucee054 14y ago
    Or you could drop stupid, stupid OOP, and then you won't have a mismatch.
    - jeltz 14y ago
      Even when you use OOP languages some tasks are really badly suited for OOP, so then just code it like it was imperative or functional. The relevant example here is reporting, where SQL is one of the most suited languages for this task. Use the right tool for the right job.
  - pielud 14y ago
    > RDBMS exist because people use to query those systems directly , does your users log into your database directly ? No, but I do. What if I want to analyze my data in some way I hadn't expected? SQL lets me do that with a single query.
    - dotborg 14y ago
      do you really need schema for this? look at web server logs, they have no schema, each line is not related with others, yet we are able to analyze logs
      - pielud 14y ago
        How do I combine data from multiple log files? How do I tweak my "queries" without scanning all of the data again? You get this kinds of things (joins, indexes, etc) for free from RDBMS. If I'm analyzing log files I have to write my own code to do it. I'm not saying RDBMS is the best solution for everything and neither is OP. But it's appropriate when you don't necessarily know every way you want to access your data up front.
      - jeltz 14y ago
        Many of the more advanced log analysis tools actually parse the logs and put them in a SQL database.
  - jerf 14y ago
    DRY is "Don't Repeat Yourself", not "Don't Repeat Ever". If your ORM fully correctly derives everything it needs from your database schema, that doesn't count as a repeat. If your ORM needs a couple of hints, but those hints are indeed extra information that your DB can't have ("this isn't just a string, it's an IP address") that doesn't count as a repeat. If you personally typed your schema into a database creation script and then you personally also typed the same schema into your ORM specification, only then are you violating DRY. Code generation is a powerful DRY tool, not something it suggests avoiding! I say that independent from the question of whether you should be using an ORM at all. If you are going to use it, either your ORM should come out of the DB or be responsible for creating the DB, either is fine, as long as you're not saying the same thing twice.
    - steveklabnik 14y ago
      > DRY is "Don't Repeat Yourself", not "Don't Repeat Ever". It's actually "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." (this advances your point even further)
      - jl6 14y ago
        And makes clear that DRY is just a handy catchphrase for the design principle of normalization.
thezilch 14y ago
For one, your DB schema can define constraints or procedures that are triggered inline to the work being done. If building those into the application layer -- not including a middleware -- you are going to pay in network IO and probably wire protocols to guarantee constraints or execute procedures. A middleware could reduce some of the costs, but then you are again moving some logic outside of your local model.
wvenable 14y ago
A fixed schema in the database means you only have one schema to deal with. But in schema-less DBMS you really have as many schemas as changes you've made. If you add a field to new records coming in, you now have 2 schemas. Every change you make is another schema. Your ORM likely represents the last iteration of that schema and then you have code to handle all the past iterations. So the point of having a schema in the database is avoiding that kind of hell.
- jt2190 14y ago
  > in schema-less DBMS you really have as many schemas as > changes you've made. Unless you migrate data with each change, which is actually easier when you don't have a static schema. The choice to do "lazy migrations" is the unusual, not typical case, as it has all of the implications that you've mentioned. Bottom line: Data normalization doesn't suddenly go out the window just because it's MongoDB.
  - wvenable 14y ago
    Usually if you have a static schema you also have SQL, which makes migrations a lot easier. If you're migrating everything with every change you might as well be using a static schema, there is hardly any downside, unless you have more rows than God. My only personal opinion is that data is much more important than code. I want to guarantee that my data is in the right structure, with the right types, and right relationships. If I have that, everything else is easy.
    - jt2190 14y ago
      > Usually if you have a static schema you also have SQL, > which makes migrations a lot easier. I'm not sure I follow. MongoDB doesn't have a static schema so there's less work to do when migrating data. No temp tables, no DDL, no disabling of triggers, etc. So my definition of "easy" in this case was "fewer things to do", not "requires less expertise." > I want to guarantee that my data is in the right > structure, with the right types, and right relationships. We know that having the right types, structure, and relationships are valuable, but since there is no context here, we can't know whether they're more or less valuable than other factors. (Note we've already assumed that the data is easily modeled in a relational structure AND in a document structure... If we're wrong about that this whole conversation may be moot.)

by dotborg 14y ago

pielud 14y ago

1. Your ORM can derive it's schema from the database's. 2. I think the main point of the post was that you can run ad-hoc SQL queries no matter how much you've denormalized. You can't necessarily do that with a NoSQL database.

camus 14y ago
Yet you are still using schemas in 2 places : not DRY , SQL just doesnt fit OOP design. Most of languages today have strong functional capabilities , that makes SQL obsolete , they have functions , event systems , RDBMS exist because people use to query those systems directly , does your users log into your database directly ? no they connect your database through middleware, that's where the job should be done.
- ucee054 14y ago
  Or you could drop stupid, stupid OOP, and then you won't have a mismatch.
  - jeltz 14y ago
    Even when you use OOP languages some tasks are really badly suited for OOP, so then just code it like it was imperative or functional. The relevant example here is reporting, where SQL is one of the most suited languages for this task. Use the right tool for the right job.
- pielud 14y ago
  > RDBMS exist because people use to query those systems directly , does your users log into your database directly ? No, but I do. What if I want to analyze my data in some way I hadn't expected? SQL lets me do that with a single query.
  - dotborg 14y ago
    do you really need schema for this? look at web server logs, they have no schema, each line is not related with others, yet we are able to analyze logs
    - pielud 14y ago
      How do I combine data from multiple log files? How do I tweak my "queries" without scanning all of the data again? You get this kinds of things (joins, indexes, etc) for free from RDBMS. If I'm analyzing log files I have to write my own code to do it. I'm not saying RDBMS is the best solution for everything and neither is OP. But it's appropriate when you don't necessarily know every way you want to access your data up front.
    - jeltz 14y ago
      Many of the more advanced log analysis tools actually parse the logs and put them in a SQL database.
- jerf 14y ago
  DRY is "Don't Repeat Yourself", not "Don't Repeat Ever". If your ORM fully correctly derives everything it needs from your database schema, that doesn't count as a repeat. If your ORM needs a couple of hints, but those hints are indeed extra information that your DB can't have ("this isn't just a string, it's an IP address") that doesn't count as a repeat. If you personally typed your schema into a database creation script and then you personally also typed the same schema into your ORM specification, only then are you violating DRY. Code generation is a powerful DRY tool, not something it suggests avoiding! I say that independent from the question of whether you should be using an ORM at all. If you are going to use it, either your ORM should come out of the DB or be responsible for creating the DB, either is fine, as long as you're not saying the same thing twice.
  - steveklabnik 14y ago
    > DRY is "Don't Repeat Yourself", not "Don't Repeat Ever". It's actually "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." (this advances your point even further)
    - jl6 14y ago
      And makes clear that DRY is just a handy catchphrase for the design principle of normalization.

thezilch 14y ago

For one, your DB schema can define constraints or procedures that are triggered inline to the work being done. If building those into the application layer -- not including a middleware -- you are going to pay in network IO and probably wire protocols to guarantee constraints or execute procedures. A middleware could reduce some of the costs, but then you are again moving some logic outside of your local model.

wvenable 14y ago

A fixed schema in the database means you only have one schema to deal with. But in schema-less DBMS you really have as many schemas as changes you've made. If you add a field to new records coming in, you now have 2 schemas. Every change you make is another schema. Your ORM likely represents the last iteration of that schema and then you have code to handle all the past iterations. So the point of having a schema in the database is avoiding that kind of hell.

jt2190 14y ago
> in schema-less DBMS you really have as many schemas as > changes you've made. Unless you migrate data with each change, which is actually easier when you don't have a static schema. The choice to do "lazy migrations" is the unusual, not typical case, as it has all of the implications that you've mentioned. Bottom line: Data normalization doesn't suddenly go out the window just because it's MongoDB.
- wvenable 14y ago
  Usually if you have a static schema you also have SQL, which makes migrations a lot easier. If you're migrating everything with every change you might as well be using a static schema, there is hardly any downside, unless you have more rows than God. My only personal opinion is that data is much more important than code. I want to guarantee that my data is in the right structure, with the right types, and right relationships. If I have that, everything else is easy.
  - jt2190 14y ago
    > Usually if you have a static schema you also have SQL, > which makes migrations a lot easier. I'm not sure I follow. MongoDB doesn't have a static schema so there's less work to do when migrating data. No temp tables, no DDL, no disabling of triggers, etc. So my definition of "easy" in this case was "fewer things to do", not "requires less expertise." > I want to guarantee that my data is in the right > structure, with the right types, and right relationships. We know that having the right types, structure, and relationships are valuable, but since there is no context here, we can't know whether they're more or less valuable than other factors. (Note we've already assumed that the data is easily modeled in a relational structure AND in a document structure... If we're wrong about that this whole conversation may be moot.)