3 ms·

Looks good for the basics, but as some other folks mentioned here, it would benefit from some articles about design, and even more importantly, rationale. I he

by nissimk 12y ago

Looks good for the basics, but as some other folks mentioned here, it would benefit from some articles about design, and even more importantly, rationale. I hear from so many programmers "why?" They don't understand the benefits of relational. This perspective ranges from old school programmers that just want to store data in the file system, to newcomers that like mongoDB or other object stores. In my point of view, the main answer to "why relational" is that with an rdbms you can answer ad-hoc questions by writing a query rather than writing a program. Even as a programmer, having the power of SQL on the server is really great for analytics. Furthermore, as an ORM hater, I would say that query results should be processed in your programming language as a table structure rather than converting to specific objects per table. If you're building a CRUD system and the screens update one or two objects/tables at a time, then an ORM is useful, but if you're doing any kind of analytics, any object structure other than a table or list of dictionaries is cumbersome and encourages code over sql which is a bad thing.

thanksgiving 12y ago
> encourages code over sql which is a bad thing Not saying you are incorrect but you made an assertion here. Can you please elaborate?
- astine 12y ago
  Not certain about the OP's reasoning, but doing aggregate functions on the database server is often more performant than doing the same in your application. This is, in part, because of the smaller result set sizes. Also, it's useful having logic baked into the database rather than your application in the case that you need a different application to connect to your database. It's a problem, for example, if you're maintaining your foreign key relationships through ActiveRecords's relations and ignoring it on the server. It makes it much easier for junk data to get in the database.
kiyoto 12y ago
>Looks good for the basics, but as some other folks mentioned here, it would benefit from some articles about design, and even more importantly, rationale. I agree about rationale, but probably in a different way. For a great many people, especially in the "data analyst camp" (i.e., people coming from finance/consulting background with mind-blowing Excel skills), SQL is not something they want to learn in the vacuum but more like necessary evil. For them, it's hugely valuable to learn how and why SQL can be useful. http://blog.treasuredata.com/2014/12/05/learn-sql-by-calculating-customer-lifetime-value-part-1/ http://blog.treasuredata.com/2014/12/05/learn-sql-by-calcula... is my humble attempt to address that issue, and it seems to have resonated well with the data analyst type folks. Just offering a non-programmer's perspective.

by nissimk 12y ago

thanksgiving 12y ago

> encourages code over sql which is a bad thing Not saying you are incorrect but you made an assertion here. Can you please elaborate?

astine 12y ago
Not certain about the OP's reasoning, but doing aggregate functions on the database server is often more performant than doing the same in your application. This is, in part, because of the smaller result set sizes. Also, it's useful having logic baked into the database rather than your application in the case that you need a different application to connect to your database. It's a problem, for example, if you're maintaining your foreign key relationships through ActiveRecords's relations and ignoring it on the server. It makes it much easier for junk data to get in the database.

kiyoto 12y ago

>Looks good for the basics, but as some other folks mentioned here, it would benefit from some articles about design, and even more importantly, rationale. I agree about rationale, but probably in a different way. For a great many people, especially in the "data analyst camp" (i.e., people coming from finance/consulting background with mind-blowing Excel skills), SQL is not something they want to learn in the vacuum but more like necessary evil. For them, it's hugely valuable to learn how and why SQL can be useful. http://blog.treasuredata.com/2014/12/05/learn-sql-by-calculating-customer-lifetime-value-part-1/ http://blog.treasuredata.com/2014/12/05/learn-sql-by-calcula... is my humble attempt to address that issue, and it seems to have resonated well with the data analyst type folks. Just offering a non-programmer's perspective.