On Fri, 13 Feb 2009 01:01:55 -0600 Larry Garfield <larry@garfieldtech.com> wrote:
So no, not a bug, but I do agree with discouraging it in most cases. The only time you'd want it is if you have a table where you expect the columns to be dynamic, which has all sorts of other maintenance issues anyway.
+1 It's always a risky bargain between extensibility, maintenance, performance and clean design. Tables should be as small as possible. It helps to keep a clear hierarchy of data and helps performances because it exploit more locality of the data. *Somehow* good design tend to produce queries that return most of the columns. When you extend tables defined upstream it means you don't trust upstream design decisions (and it will bite you) or you're very very tight with resources and you've been bitten by performance problems. Ideally I don't want to know why Drupal core decided to put those columns in users. I'd expect they made a general choice that help extend the user object and keep the base user object as thin as possible. I don't want to mess with their decisions, their API, their responsibility of the cost of building up a base user object, upgrading it to newer Drupal versions... *Dynamically* extended tables makes the cost of a service unpredictable. Service x add column A, B, C. Service y add column D, E, F. ... wooohp. Explicitly naming columns make refactoring apparently more boring but definitively more under control. It promotes better coding making people more aware of what they're doing. It makes easier to deploy tests and it makes easier to find places where you've to refactor. As with set/get methods in OOP it makes easier to hide where data are actually coming from. It gives an order to columns making select easier to reuse correctly. Not only it helps to spot errors, but it spots them earlier. The first time you'll have to refactor 100 places where you had to add a column (say you moved from name -> name + surname) it will give you a clue there is something that doesn't work with your design... but at least it will tell you all the 100 places you've to refactor. Every time you write a SELECT * it is a missed chance to use grep as a debugging tool. This alone is worth getting rid of all the SELECT * and even n.* And if it is not for debugging purposes it helps to understand the code (especially for contrib). Where does this stuff come from/is used...? let's grep it. -- Ivan Sergio Borgonovo http://www.webthatworks.it