database

Now that we have four more weeks before D6 code freeze, maybe it is possible to add join relationships/foreign key support into Schema API 1 after all. Otherwise, it will be another year before this info is in core. Note that this info does not really have to be in core---it can be added by a contrib module hook_schema_alter. But a lot of people would be pretty psyched to have referential integrity for pgsql built in to D6.

Now that the schema has been committed to core, I wanted to open up a thread where people could discuss additions an enhancements to the API.

I posted a patch to add a db_rename_table over on #147285. I've love to see it get in before the feature freeze.

Okay, since i'm busy creating a fairly heavy multisite (W.I.P.) let me share some research i've done about shared database tables etc.

We're starting with a multisite that has different content on each site, but are using the same userbase for each site, we're operating from a single database
We're starting from the drupal core essentials perspective, meaning we start with no modules enabled besides drupal required core.

Now that Schema almost has a driver for PostgreSQL I needed to resolve the data type issue. I like Frando's approach (I seem to say that a lot) of storing 'type' and 'size' separately because it makes a variety of things easier. For example:

One thing that becomes possible when Drupal can access its own database schema is that queries which currently are performed separately can instead be performed together. In particularly, I think it might be possible to load an entire node with a single SELECT query or, at least, in far fewer than Drupal currently uses. Working proof of concept code is already in the Schema module; it loads all CCK fields, comments, and author info in one query. Loading more things only requires adding a join entry to the schema data structure (see below).

One of the first things we to do is define the data structure that modules will use for declaring their tables. Schema module, Frando's patch, dopry's patch, and CCK fields all use different structures though their underlying approaches are basically the same. We need to decide what kind of information the data structures must contain and can contain. This will obviously include at least columns (name, type, length, nullable, default), indices (name, columns, primary vs unique vs multi), and join/relationship information.

Welcome to the Database Schema API group. A number of different Drupal developers have independently suggested and/or coded various approaches to abstracting table creation/alteration. The idea finally seems to have reached critical mass and I suggest that we will be best served by combining everyone's efforts on the topic. Hence, this group.

By way of background, here is some recommended reading on the topic:

So, you want to speed up your large site? Well, start by cleaning up your SQL if you're accessing large tables. We are running Drupal on top of MS-SQL for a client. We have one table that has 7.5 millinon rows in it. Now, I had mentioned what I am about to talk about in another post before, but I know have some hard numbers to base it off of.
So anyway, this table had 7.5+ million rows, and the page was loading mighty slow. Running it 10 times, Devel query showed where I was bleeding...more like gushing time:

<

ol>

Hello flexinoders,

I am working on a new, better 4.7 release, as you may have noticed. This is the first step in preparation of a 5.x release.

For that, I am looking for real-world databases to test and develop the upgrade with.
Do you have 4.6 flexinode data lying around?

One of the most used features of WSUM's current site is the playlist entry and search.  Even with the interface being clunky, the DJ's at the station do a fantastic job of real-time entry to the db. In my live playlist entry post, I mentioned how the DCMA requires this information now.  While I am not as concerned with that as I am getting the information to the public, I would like to examine the possibilities of starting to get live playlist entry into or connected to station.module.