Tag Info

Hot answers tagged

64

When he reviewed the database schema he stated that all foreign keys and other such constraints should be removed as this is business logic and should be applied within the business layer. Then he's an idiot, and some excerpt from your codebase is likely to end up on The Daily WTF someday. You're absolutely right that his approach doesn't make sense, ...


8

Reasoning about a query's meaning (i.e. the results it should produce) using the naive procedural approach you describe is perfectly fine. As you say, with complex queries it's often the only easy way to work out what's going on. The problem would be if you used this reasoning to infer properties about the query execution (such as time complexity or memory ...


1

You are indeed able to precisely determine what a query will return by using logical reasoning as you described. What SQL does not guarantee is how the engine will find this result. It will give the same result as if it used the logical steps you describe, but how it actually finds the result depends on a number of factors and implementation details. For ...


1

It depends on whether or not you need to do anything "interesting" with that additional, client-specific data. In practice, it is unlikely that any processing will take place on custom fields, since you would have to provide that processing yourself, with some sort of plugin infrastructure or provide custom builds for each client, an arrangement which can ...


1

I'll discourage the option to use triggers in such case. You might be better off thinking in API terms to your model. As the comments point out, use stored procedures, as they will be easier to debug in case something goes not according to plan, keep in mind that you have a quite complex situation ;-) Some helpful references, wikipedia article about ...



Only top voted, non community-wiki answers of a minimum length are eligible