I’ve been involved in a number of projects that use custom tables, some of which are quite extensive. For the extensive ones, I’ve found that using a custom table prefix works well. I create and update tables in my regular MySQL application, then use Bob Ray’s “CreateXpdoClasses” snippet (found here: Bob's Guides | Custom DB Tables) on the site to create the component schema and class files. Then, whenever I update the tables, I just rerun this script and all the schema and class files get updated accordingly. It’s fast and easy.
There are some who say the best idea is to just use the default MODX prefix (modx_, or whatever you use), and I see why that’s desirable in many cases, especially if you’re developing an extra for distribution. But for custom work that won’t go public, I’m curious to see which approach people have used.
Mark Hamstra posted this a few years ago:
modx_prefix is only a default, and the idea of prefixes is that you can have multiple MODX installations (or even different CMSes) in a single database table. By using a custom prefix, you remove that flexibility.
That makes sense, but I can also argue the opposite: using a custom prefix allows you to share data across multiple MODX installations.
On the other hand, Bob Ray says this on his Custom DB Tables page (referenced above):
It’s a good practice to use a different table prefix than the one in your MODX database . . .
MIGX DB has an option to set up custom tables with custom prefixes, and Bruno replied to one person’s query with this:
for working with custom-tables inside modx, you can do it this way:
1. give all your tables for your package a unique prefix, lets say ‘mybookings_’
. . .
7. set the listbox to ‘use custom prefix’ and put into custom-prefix: ‘mybookings_’
Has anyone used custom table prefixes when creating a system that uses custom data?
If so, why?
If not, why not?
What pros and cons have you found using either approach?
Have you changed your opinion over time?