3 ms·
All of these, save for the payment processor one, can and should be done in sql. I think you are uncomfortable with SQL. Ultimately it is the designer's choic
by moheeb 15y ago
All of these, save for the payment processor one, can and should be done in sql.
I think you are uncomfortable with SQL.
Ultimately it is the designer's choice where the business rules are handled...but to abstract those rules to levels above where the 'business' actually happens seems like a poor practice.
- pak 15y ago'Business' does not just happen within the database! You will have to perform logic based on events that occur elsewhere, e.g. on the network or within outside data sources! And to say that something should be done in SQL just because it can is patently absurd--do you know how much performance suffers as soon as you start roping in subqueries and calculated values? Half of the things I listed would require stepping outside of indexed columns in awkward ways--that was kind of my point. Good luck keeping that performant past a few million rows. In fact, I would love to see you design a query that branches on the condition that the item is out of stock and automatically returns the top 3 equivalent parts for each brand using a junction table containing equivalencies, ordered by a column in the junction table containing the closeness of fit. Go ahead, humor me. Then try to pretend that that query will ever stand up under scale.