5 ms·

I couldn't agree more. The code first design is what kept me away from Rails. I'm sure they have sensible approaches as well, but unfortunately I couldn't get o

by mnm1 8y ago

I couldn't agree more. The code first design is what kept me away from Rails. I'm sure they have sensible approaches as well, but unfortunately I couldn't get over my prejudice that anyone who teaches the creation of the database through the app's code instead of actually designing the database is someone I don't want to follow or learn from and whose framework I don't want to use even if it provides alternatives (I hope it does). Database design in a CRUD app is by far the single most important task. Show me your code and I know nothing, show me your data structures and I understand the whole app never applied more. The consequences of not following this advice I see everyday at my current job where we are stuck with an ORM that needs at least 3-4 files modified for each entity change and that requires management using an external GUI tool. The ORM adds 10x overhead to already unoptimized SQL queries so optimizing the queries is never a problem because the system's overhead is so slow even if it was possible to make the queries run in zero time, the overhead would still kill us. 10x. Query is 10ms and overhead is 100ms. And the trade-off for this? Nothing but a shitty ORM that makes no sense (Doctrine 2/PHP) and slows down development a few times over as well. Changing even the name of a column requires editing multiple files. We have camelCase, snake_case, and kebab-case for all our entities and depending on where you are in the system, a different case is required. Using the ORM to generate entities after you're in production? Don't make me laugh. That's impossible. And this isn't even the worst ORM I've used (though it's close). Everything the author mentions and then a whole bunch of stuff that's a million times worse has resulted from this drive to abstract away the most important component, the database, and not have it be the single source of truth. Frankly, it's fucking stupid and beyond maddening, not to mention slow and due for a rewrite. Never again will I tolerate this kid of design that ORMs encourage or the use of ORMs at all, especially if they replace solid database design. I'll leave that kind of fuckery and stupidity to the rookies.

rimliu 8y ago
What’s stopping you from designing your database in Rails? You can spend all the time you need designing it, and then just write your design down in migrations/models.
- jessaustin 8y ago
  I've never used Rails, but I will be surprised to learn this "migrations/models" abstraction allows the full range of foreign keys, indexes, triggers, constraints, stored procs, etc. without which we might as well just be on NoSQL... Not that there is anything wrong with that in principle, but in many situations that's not what we want.
  - house9-2 8y ago
    Rails migrations give you `foreign keys, indexes, constraints` but not `stored procs` - there are hacks to make it work with stored procs if you really really want to. `triggers` are rarely used in rails applications, but nothing to stop you from using them. The rails model is an ORM (Active Record) and makes working with relational databases a breeze. Rails migrations f^ing rule: http://guides.rubyonrails.org/active_record_migrations.html http://guides.rubyonrails.org/active_record_migrations.html
  - barrkel 8y ago
    ActiveRecord isn't really an ORM. It's a way of building queries against relational data, and associating some methods with the tuples you get back (which might not even be full rows). It also has a bit of support for C, U and D, but it's strongest in R. Although many queries won't fit in its model, it's trivial to inject snippets of SQL where needed. What it is not is a way of mapping databases to models. The models pretty directly model the database, rather than the other way around. Quite different to something like JPA.
    - pmontra 8y ago
      Interesting way to see it. Could you please name a real ORM so I can understand the difference?
      - barrkel 8y ago
        Something that doesn't mandate your ancestor, like JPA.
rhizome 8y ago
the creation of the database through the app's code instead of actually designing the database What is the distinction you're drawing here, migrations vs. DDL?
- mnm1 8y ago
  Not at all. Sitting down, thinking through, and designing an actual schema vs. writing a bunch of code first for entities without thought to the big picture, design of the database, or how this will be implemented in the actual db.
sethammons 8y ago
Can you just not use Doctrine and make hand coded models that are optimized for your use case? Or make a microservice that accesses the data, and query that API?
- mnm1 8y ago
  In our api, I ended up rewriting most of the db access to not use it but it's not as performant as it could be due to needing a custom serializer and naming requirements in place. Also the code is now half orm, half sql. The other app, I couldn't do even that. It's just too ingrained into the app sadly. At some point some of it will have to be rewritten, especially the api and I plan to use clojure where this issue won't exist.

by mnm1 8y ago

rimliu 8y ago

What’s stopping you from designing your database in Rails? You can spend all the time you need designing it, and then just write your design down in migrations/models.

jessaustin 8y ago
I've never used Rails, but I will be surprised to learn this "migrations/models" abstraction allows the full range of foreign keys, indexes, triggers, constraints, stored procs, etc. without which we might as well just be on NoSQL... Not that there is anything wrong with that in principle, but in many situations that's not what we want.
- house9-2 8y ago
  Rails migrations give you `foreign keys, indexes, constraints` but not `stored procs` - there are hacks to make it work with stored procs if you really really want to. `triggers` are rarely used in rails applications, but nothing to stop you from using them. The rails model is an ORM (Active Record) and makes working with relational databases a breeze. Rails migrations f^ing rule: http://guides.rubyonrails.org/active_record_migrations.html http://guides.rubyonrails.org/active_record_migrations.html
- barrkel 8y ago
  ActiveRecord isn't really an ORM. It's a way of building queries against relational data, and associating some methods with the tuples you get back (which might not even be full rows). It also has a bit of support for C, U and D, but it's strongest in R. Although many queries won't fit in its model, it's trivial to inject snippets of SQL where needed. What it is not is a way of mapping databases to models. The models pretty directly model the database, rather than the other way around. Quite different to something like JPA.
  - pmontra 8y ago
    Interesting way to see it. Could you please name a real ORM so I can understand the difference?
    - barrkel 8y ago
      Something that doesn't mandate your ancestor, like JPA.

rhizome 8y ago

the creation of the database through the app's code instead of actually designing the database What is the distinction you're drawing here, migrations vs. DDL?

mnm1 8y ago
Not at all. Sitting down, thinking through, and designing an actual schema vs. writing a bunch of code first for entities without thought to the big picture, design of the database, or how this will be implemented in the actual db.

sethammons 8y ago

Can you just not use Doctrine and make hand coded models that are optimized for your use case? Or make a microservice that accesses the data, and query that API?

mnm1 8y ago
In our api, I ended up rewriting most of the db access to not use it but it's not as performant as it could be due to needing a custom serializer and naming requirements in place. Also the code is now half orm, half sql. The other app, I couldn't do even that. It's just too ingrained into the app sadly. At some point some of it will have to be rewritten, especially the api and I plan to use clojure where this issue won't exist.