-2

A while ago I wrote a question asking about storing easily queryable data associated with a given attachment.

The recommendation that I received at the time was that I should avoid using the WP attachment metadata because it cannot be quickly queried for. Instead, what was recommended (and what I opted to implement) was to store all of the values in an array within an option. This works, but the design of the thing makes me want to cry. It goes agains every fiber of my being which says, "that should be its own table!" See what I mean: http://pastebin.com/hBfrxaiH

So my question is, under what circumstances should a WP developer consider creating a custom table to support their plugin? I know that custom tables are generally frowned upon, but I feel like what I'm currently doing is an abomination and really would like to achieve my plugin's needs in a cleaner way.

My thinking with a custom table is that not only would it clean up this design disaster, but I would also have a higher degree of control over how and when values are loaded from the DB rather than just pulling EVERYTHING out before being able to do anything intelligent with the data. Additionally, unlike the current solution, a custom table would scale -- the current solution most definitely does NOT scale.

2
  • Please don't use external sources like pastebin to add code to your question. Add your code directly to your question. Also don't ask a question to just mark it as a duplicate. Thank you Commented Jul 30, 2014 at 9:14
  • @PieterGoosen, Firstly I did not create it in order to mark it as duplicate. I created it then realized it was a duplicate after the fact. Secondly, have you ever worked on any of the SE sites? With a large dump such as what was included on the PB link it is more than appropriate to place the content externally, especially since the question can function without the data, but adding it provides more context. Thirdly, you may want to work on the way you come off to WPSE users as your comment sounded quite rude.
    – Dan
    Commented Jul 30, 2014 at 12:13

1 Answer 1

-2

Never.

The only exception is if none of the WP tables structure in terms of indexing meets your needs, but that is very very rare.

4
  • 1
    "Never", "... except..." ;). For the balance of arguments, I'd like to counter this by saying too often developers shoe-horn their data into the wp_posts where it is not suited, and this isn't "rare". You hint at this, but "never" is far too stronger a word. Each case should be taken on its merits, as there are pros and cons on both sides. But as such, the question isn't a good fit for the site as there is no definitive answer. Commented Jul 30, 2014 at 9:30
  • You say "shoe-horn" as if it is bad without giving any example for that. I say that this kind of shoe-horn is good and the proper thing to do. I am willing to bet that on real live sites where it actually matters your implementation using the option table will be faster then your implementation with your own table, with maybe a cost of some totally insignificant memory overhead, and your table solution will take more time to develop and will be harder to maintain. So yes, unless you have some extremely unique requirement the answer is never. Commented Jul 30, 2014 at 9:49
  • @MarkKaplun, You must know some pretty awful DB developers if you can say that "your" table implementation would be slower than the solution provided in the question. You'd be hard pressed to have a lower performing, less scalable solution. I hope you realize that using absolutes makes your answer completely non-credible.
    – Dan
    Commented Jul 30, 2014 at 21:59
  • 1
    I never understand why people bother to ask questions on SE if they know the answers better then anybody else.,,, The slowest thing you can do on wordpress is a DB query. However inefficient your PHP code is it will be much faster to get extra info in one query then have two more precise queries. Even if for some reason you prefer not to fetch all data in one query then the options table exists explicitly to provide key to value mapping and there is no need to create a new table for that. And there is also caching and hooks provide by the options API that will not be available for your table. Commented Jul 31, 2014 at 2:53

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