3 ms·

Hmm. Not to nitpick, but what if: - you're running a promotion - the price changed in between the time the person added it to their shopping cart and checkou

by pak 15y ago

Hmm. Not to nitpick, but what if: - you're running a promotion - the price changed in between the time the person added it to their shopping cart and checkout - two people are processed for a payment on the last item in inventory at the same time - there are different options on the item, e.g. color, that change the price - other people bought the last item in inventory already, but there's an equivalent product at the same price - the person bought the product using a combination of real money and gift card money, which the payment processor does not handle - the person bought other things in the same transaction, e.g. a gift card, that do not have an inventory ID Those are just a few cases off the top of my head, but the short end of it is that expressing all of this with a combination of SQL and client-side logic is just madness. If you're saying that we don't need to write business logic in PHP any more, I think you just don't work with the same constraints that most businesses do.

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.

by pak 15y ago

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.