8

When creating Addons should we utilise the underlying database structure provided by ExpressionEngine for storing large numbers of items / information. For instance use channel entries? Or should you keep it all separate and craft your own tables / relationships etc?

If I were to take a stab at answering this myself, I'd probably say use as much of existing expressionengine tables infrastructure as possible as there isn't any great reason to re-invent the wheel. My only concern is how you might limit access to say channel entries (if you've used them) for your addon. Say if you want the user to edit information in a particular way (and it's not the standard EE way of doing it). Or is this the problem, should they be doing it the EE Way?

Is it / should it be handled differently if it's a custom Addon for one site you are working on, as apposed to creating a commercial addon?

8

My opinion is that it very much depends on the add-on. Something like Carthrob, for instance, lends itself perfectly to using the native channel entries table as data can be accessed using the channel entries tag and edited in the CP in the usual way. So in this instance, there is no need to re-invent the wheel.

If the structure of the data you need to store doesn't lend itself to a channel entry format, you are better off creating your own tables.

Hope this helps, Joe

| improve this answer | |
6

My take: if this is a bespoke add-on for private use, only use exp_channel_entries and exp_channel_data if the data you're storing can added/edited using the standard EE publish/edit screens and follows the conventions of those tables (matching entry_id and channel_id, etc). Otherwise you're setting up any future developer for a whole lot of confusion, and you may get unpredictable results from third party add-ons which interact with channel data.

If it's an add-on you intend to distribute, definitely use your own database tables, no question.

Generally-speaking, the only data an add-on should be storing in default EE tables is its extension settings in the settings column of its exp_extensions row (if applicable).

| improve this answer | |
3

General rules of thumb:

  1. If you find yourself altering tables (adding columns for example) your add-on should create its own table instead.
  2. If you can fit your data in core tables, by all means, do so (if you're creating new entries or editing them, for example)
  3. Use your own tables within the same database for things like configuration data, and business-logic (For example an SEO module should have its own table to save title and description tag info per entry, and a config table for storing user configuration such as robots.txt value)
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.