“so while the default install would only have 10 or so relationships defined, if someone wanted to do something esoteric they could.”
Ah, sorry for my misunderstanding. Here I do concur.
“As for backwards compatibility with plugins, only those that access the db directly would have a problem; they shouldn’t be doing that in the first place, but I understand why they do.”
Well,… As an aside, I write a lot of custom plugins, and I’d say a large amount of my code accesses the DB directly. Why? Because either 1.) what I need done is simply not possible using only the API functions in PHP provided by WordPress, 2.) it is not performant enough to use the provided API functions, 3.) I need to use custom tables and I need to relate them to existing tables (Note: I only add tables as a last resort when none of the tables provided by WordPress can be used instead.)
We could reduce the number of times someone needs to do #1 by adding more API functions, for sure, and I’d love to see that. #2 is a case-by-case basis which is often combined with #3. And #3 means either adding general purpose versions of those types of tables we need which could minimize the need to create custom tables but never eliminate it.
So IMO a blanket “You are doing it wrong if you access the DB directly” is unrealistic for people trying to meet client needs and can only be minimized but never eliminated.
“TL;DR: To me this sounds like “WP did it this way, we should too”. We should certainly learn from their mistakes, but we should also remember that we’re not WP.”
I can’t speak for Greg, but reading his comments I didn’t see that he implied that, and I explicitly stated the opposite, i.e. create one relationship table instead of many like WordPress did with meta.
That said, IMO ClassisPress won’t be a “Classic” version of “Press” if it does not maintain at least reasonable compatibility with WordPress, otherwise then it is really something else.
And that means not going too far out away from WordPress, such as replacing existing tables with NoSQL, though an option for using NoSQL might make sense.
BTW, one of my hopes is that we can get WordPress to adopt some of the work we do for ClassicPress so the forks do not have to diverge too much and plugins can continue to easily work on both platforms.
“One of my biggest gripes about WP/CP is that we’re sitting on top of a relational database and almost entirely treating it as a dumb key/value store”
When I came to WordPress, I hated the key/value store. After all, I starting my career as a relational database instructor.
But now with almost 10 years of working with WordPress I have come to feel that is it one of WP’s better features. It is one of the reasons that so many plugins can work together w/o conflict. It is also a major reason why WP is so much easier to deploy than Drupal, for example.
Back in the 80’s and 90’s I’d spent lots of time trying to get my database schemas correct, and they never was. I was constantly having to change them as new requirements arose, in part because relational database does not model real-world entities without tradeoffs, and those tradeoffs often require schema changes when the requirements change.
But WordPress’ key-value store has been mostly immune to the need for constant schema changes. And that has allowed me as a developer to focus more on the requirements of the solution instead of how I store its data.
I am not saying there is no value in a nicely designed 3rd normal form relational database – there definitely is, especially for performaces – but there is also a value to key/value stores as I described above, and I would hate to loose those benefits in ClassicPress.
“and as an added bonus, serialised data too.”
I am 1000% percent with you there, though! Except in
wp_options. It makes sense to me in
wp_options (for the most part.)
P.S. All the above are just one man’s opinion. I have no authority to make decisions related to ClassicPress, I am just someone who wants to contribute to make it better in the ways I see that if could be better.
~ posted by Mike Schinkel