Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I can see both sides of the question. However, given that you say there are only about 40 tables, it seems to me that the complexity of interacting with, say, 30 other tables outside your area of expertise is minimal. I'd vote for writing the queries that do the complex joins. After all, other than knowing the exact columns in the table, which should be easy, all you really need to know is any special relationships or special meanings that those tables use.</p> <p>But the other fact that might make the decision for me is what are the performance requirements? If the system is currently fast enough, and the hardware and table sizes are such that it will still be fast enough using separate queries for each table, go ahead and do it using the 2nd approach if it makes everyone's life easier. But on the other hand, if <em>anyone</em> has ever complained about speed, or if the tables are likely to grow without bound in the future, or your number of users is likely to increase, do it using the method which has the best hope of being faster.</p> <p><strong>RESPONSE TO COMMENT:</strong> Not necessarily. Say the product module added 5 new columns. Either you were not using those already, and therefore not joining to them or retrieving them, and would not be affected regardless of which method you chose, or you need them and have to write new code for how to deal with them. At any rate, the changes to your side would be the same whichever method you chose. Say the Product module renamed or deleted 3 columns. Then your side would have to change how it handled the returned values, independent of how the interface was written. I see what you are getting at, but the bottom line, IMHO, is that if you use fields involved in the change, you have to make code changes. If the fields are not used by you, you don't. The "ripple affect" you mention should not exist if you only fetch columns you want, as opposed to using <code>select * from tbl</code> queries.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload