4 ms·

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/

by 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.
- senotrusov 8y ago
  Rails provide ruby DLS for migrations but you can always put plain SQL in that migration files. I do this most of the time and the Rails conveniently tracks which script needs to be executed against particular database state and runs them for me. I find myself rarely do triggers. Not because I can't. It's just more handy to do on the ActiveRecord layer having access to all my ruby code. Indexes, indexes on PL/pgsql procedures, foreign keys and constraints – they absolutely have their place in Rails applications. Although you could do a rather complicated SELECT's with ActiveRecord, sometimes, for particular queries, I prefer to create a database VIEW and then point the ActiveRecord model to it.
  - toasterlovin 8y ago
    > Although you could do a rather complicated SELECT's with ActiveRecord, sometimes, for particular queries, I prefer to create a database VIEW and then point the ActiveRecord model to it. Database views + ActiveRecord are a super power.
- joevandyk 8y ago
  There’s nothing that stops you from using all those things in Rails migrations.
  - jessaustin 8y ago
    There seems to be a range of opinions in these replies.
    - pmontra 8y ago
      Ultimately you can write Rails migrations in SQL. That's a fact. There are two problems with that. One is that I discovered with surprise that some developers, not only in Rails projects, don't know SQL. The other is that you still have to synchronize those migrations with changes to the models of the framework (example: add belongs_to, has_many, etc.) even if ActiveRecord autodiscovers the fields of the tables. The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Think about a project with microservices in many different languages and it can easily become unmanageable. "We added a foreign key from here to there, everybody update their representation of the schema." Multiply for a few times per day.
      - toasterlovin 8y ago
        > The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Think about a project with microservices in many different languages and it can easily become unmanageable. "We added a foreign key from here to there, everybody update their representation of the schema." Multiply for a few times per day. Isn't the point of microservices to wrap the database so that other applications don't have access to it? And if you're at a stage where you're rapidly iterating on your data model, maybe start with a monolith where iteration is less costly?
      - mnm1 8y ago
        > The other is that you still have to synchronize those migrations with changes to the models of the framework (example: add belongs_to, has_many, etc.) even if ActiveRecord autodiscovers the fields of the tables. Yeah, this is the part that's the problem, not the migrations themselves. Keeping this boilerplate in sync with the db is the bane of my existence in my framework and is a completely unnecessary task. Using the ORM itself is even worse, but I digress. In apps I started from scratch, I dropped all that garbage in favor of repositories that send straight SQL to the db and all these issues dissapeared, including the slow 10x query overhead. > The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Maybe it's true for Rails, but there are plenty of frameworks that work fine without ORMs, ActiveRecord, or other such nonsense. To me, such systems are a step back from straight SQL and add unnecessary overhead that only gets in the way and slows down development. Having the SQL in a file and auto-generating functions on top like HugSQL does in Clojure (https://github.com/layerware/hugsql https://github.com/layerware/hugsql) is by far the most optimized system for db access I've seen. Other languages have these types of libraries as well. Another option is query builders. It's simply false that a db access framework needs to be configured with boilerplate based on the db schema. Yes, that's the case for the idiotic ORMs, but certainly not the case for other libraries which are available in pretty much every language.
mnm1 8y ago
Rails wants to generate the database for me rather than generate the metadata it needs from the db. That's how it's presented by default anyway. I'm sure one can use it the other way, it was just never obvious how and I never bothered to pursue it. I shouldn't have to write a class for each db table or maintain other such boilerplate nonsense that easily gets out of sync with the db. The database already has sql which is more powerful and useful than any db framework I've encountered so far. Why would I turn away from that for a framework that has its own dsl? That's crazy. Rails is just one example of such a design, a design I try to avoid as it leads to pain and in my experience terrible architecture and code.

by 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.
senotrusov 8y ago
Rails provide ruby DLS for migrations but you can always put plain SQL in that migration files. I do this most of the time and the Rails conveniently tracks which script needs to be executed against particular database state and runs them for me. I find myself rarely do triggers. Not because I can't. It's just more handy to do on the ActiveRecord layer having access to all my ruby code. Indexes, indexes on PL/pgsql procedures, foreign keys and constraints – they absolutely have their place in Rails applications. Although you could do a rather complicated SELECT's with ActiveRecord, sometimes, for particular queries, I prefer to create a database VIEW and then point the ActiveRecord model to it.
- toasterlovin 8y ago
  > Although you could do a rather complicated SELECT's with ActiveRecord, sometimes, for particular queries, I prefer to create a database VIEW and then point the ActiveRecord model to it. Database views + ActiveRecord are a super power.
joevandyk 8y ago
There’s nothing that stops you from using all those things in Rails migrations.
- jessaustin 8y ago
  There seems to be a range of opinions in these replies.
  - pmontra 8y ago
    Ultimately you can write Rails migrations in SQL. That's a fact. There are two problems with that. One is that I discovered with surprise that some developers, not only in Rails projects, don't know SQL. The other is that you still have to synchronize those migrations with changes to the models of the framework (example: add belongs_to, has_many, etc.) even if ActiveRecord autodiscovers the fields of the tables. The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Think about a project with microservices in many different languages and it can easily become unmanageable. "We added a foreign key from here to there, everybody update their representation of the schema." Multiply for a few times per day.
    - toasterlovin 8y ago
      > The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Think about a project with microservices in many different languages and it can easily become unmanageable. "We added a foreign key from here to there, everybody update their representation of the schema." Multiply for a few times per day. Isn't the point of microservices to wrap the database so that other applications don't have access to it? And if you're at a stage where you're rapidly iterating on your data model, maybe start with a monolith where iteration is less costly?
    - mnm1 8y ago
      > The other is that you still have to synchronize those migrations with changes to the models of the framework (example: add belongs_to, has_many, etc.) even if ActiveRecord autodiscovers the fields of the tables. Yeah, this is the part that's the problem, not the migrations themselves. Keeping this boilerplate in sync with the db is the bane of my existence in my framework and is a completely unnecessary task. Using the ORM itself is even worse, but I digress. In apps I started from scratch, I dropped all that garbage in favor of repositories that send straight SQL to the db and all these issues dissapeared, including the slow 10x query overhead. > The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Maybe it's true for Rails, but there are plenty of frameworks that work fine without ORMs, ActiveRecord, or other such nonsense. To me, such systems are a step back from straight SQL and add unnecessary overhead that only gets in the way and slows down development. Having the SQL in a file and auto-generating functions on top like HugSQL does in Clojure (https://github.com/layerware/hugsql https://github.com/layerware/hugsql) is by far the most optimized system for db access I've seen. Other languages have these types of libraries as well. Another option is query builders. It's simply false that a db access framework needs to be configured with boilerplate based on the db schema. Yes, that's the case for the idiotic ORMs, but certainly not the case for other libraries which are available in pretty much every language.

mnm1 8y ago

Rails wants to generate the database for me rather than generate the metadata it needs from the db. That's how it's presented by default anyway. I'm sure one can use it the other way, it was just never obvious how and I never bothered to pursue it. I shouldn't have to write a class for each db table or maintain other such boilerplate nonsense that easily gets out of sync with the db. The database already has sql which is more powerful and useful than any db framework I've encountered so far. Why would I turn away from that for a framework that has its own dsl? That's crazy. Rails is just one example of such a design, a design I try to avoid as it leads to pain and in my experience terrible architecture and code.