[camus]

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.

[jerf]

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]

> 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]

And makes clear that DRY is just a handy catchphrase for the design principle of normalization.

[pielud]

> 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]

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]

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]

Many of the more advanced log analysis tools actually parse the logs and put them in a SQL database.

[ucee054]

Or you could drop stupid, stupid OOP, and then you won't have a mismatch.

[jeltz]

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.