Running Weblogs with Slash

Appendix B. Common Slash Database Tables

Slash is designed so that users (and administrators) should never really need to know anything about the underlying database, in normal operation. For programmers, the database is abstracted behind a standard programming interface. Furthermore, most of the display and calculation functions hide the existence of the database.

Keep in mind that when (not if) these tables change, any assumptions you have about the database will probably break your code. If the API is not flexible enough for your needs, consult the Slash development list to see if anyone else has found a solution. Even if nothing comes up, you stand a better chance of having a patch integrated into the main distribution. Your career as a Slash site administrator will be long and happy if you do not have to merge several custom patches with each upgrade. That said, there are several reasons why you might need to explore the database schema:

You want to write a plugin

Most plugins will need to use only the API provided by Slash::DB, but certain data structures (such as $user) correspond very closely to table fields.

You want to use an unsupported database vendor

You may also wish to use a database not directly supported by Slash, especially in an organization that is standardized on one platform. Porting Slash to a new database may be your only recourse. As of Version 2.2, Slash has run on three database platforms: MySQL, PostgreSQL, and Oracle. The Slashteam actively supports ...