I always look at the use case when deciding if I should add to a core
table or go with a separate table all together. Basically I base it on
any queries that are going to run. In your situation, I would add to the
core table if you will be setting sort and query criteria to the core
columns and your new ones. If you aren't going to query on those
columns, or sort on them, then a second table is probably better and
just join it.
So:
SELECT n.*, c.* FROM node n INNER JOIN customer c ON c.nid=n.nid WHERE
n.status=1 AND n.promote=1 ORDER BY n.created DESC
That would be fine since all the selection and sort stuff is done on the
node table, but:
SELECT n.*, c.* FROM node n INNER JOIN customer c ON c.nid=n.nid WHERE
n.status=1 AND n.promote=1 AND c.customer="acme" ORDER BY n.created DESC
That would be better adding the columns to a core table, since you are
going to get into some nastier queries that can easily go to tablesorts
and temporary tables.
Just my $.02
Jamie Holly
http://www.intoxination.net
http://www.hollyit.net
On 7/12/2010 12:46 PM, nan wich wrote:
Pierre, if the data was that important, I would add it to another
table and maybe even normalize it. This is stuff like the name
and company of the commenter - both about as important as the email
address that is already there. This is just not serious stuff in this
case.
/*Nancy E. Wichmann, PMP*/
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L.
King, Jr.
------------------------------------------------------------------------
*From:* Pierre Rineau <[email protected]>
*To:* [email protected]
*Sent:* Mon, July 12, 2010 12:33:35 PM
*Subject:* Re: [development] (no subject)
Le lundi 12 juillet 2010 à 09:19 -0700, nan wich a écrit :
>
> Is there an official stance on using hook_schema_alter to add columns
> to core tables? For example, we collect additional data on anonymous
> comments and want to actually save that data. Rather than creating
> another table (and subsequent JOINs), I'd just as soon stuff that data
> into the comments table, where it belongs. Should we ever disable
> comments (unlikely), we probably wouldn't mind losing that data too.
>
> Nancy E. Wichmann, PMP
>
> Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L.
> King, Jr.
I would say, create a new table instead of populating core one.
Each time you'll update your statistics, it will update the core
database row, which should have not been updated. It will break most of
the DBMS query cache, you will drastically lower your site performances
if you have a lot of data. Ever worst, some DBMS do important physical
row moves on each update (like PostgreSQL), this is no good, if you
don't have to update a row, don't update it.
You will may also experience some weird behaviors, like other modules
dropping rows and recreating them identically, then loosing your
statistics if they do not use drupal_write_record().
Pierre.