[wp-hackers] questioning the efficiency of using custom post types

[Chris Taylor - stillbreathing.co.uk]

Interesting discussion.

If the only downside of using custom tables is records not appearing
in the WP search results (I'm not convinced this is the only
downside), is there a way or has there been any thought put into
allowing plugins to "register" their custom tables with the WP search
system so they are included in any searches? For example
(psuedo-code):

wp_search_register_custom_table_fields( "table_name", array(
"field_1", "field_2"
));

Would give the normal search results *plus* a search of the fields
"field_1" and "field_2" in the "table_name" table. This could be an
option in the plugin, giving site admins the option to include the
custom data in search results.

The psuedo-code above misses out obvious things like the name of
fields to show for the search result URL, title and description.

Chris


On Fri, Nov 4, 2011 at 8:27 PM, logikal16 <logikal16 at gmail.com> wrote:
> Ah, the age old question of custom tables vs postmeta.
>
> postmeta:
> (+) Searchable by default WP search(!)
> (+) Uses native WP tables (more future-proof)
> (+) Fewer JOINs for queries involving multiple post types
> (-) Less efficient storage (separate postmeta row for each field
> value, stored as LONGTEXT)
>
> custom tables:
> (+) Field types can be enforced by MySQL (INT vs DATETIME)
> (+) More efficient storage (instead of all values stored as LONGTEXT)
> (+) Faster/fewer queries when querying a single post type
> (+) Fewer rows of data per item
> (+) Fields can be indexed
> (-) Search is NOT automatic. The more custom tables, the more complex
> your custom search will become.
>
> For the vast majority of WP sites, the performance difference is
> negligible. If you NEED all your content to be searchable, then either
> go the postmeta route or prepare to write your own custom search.
>
> If you're using WP to make a custom app (data-heavy, with plenty of
> filters), then the custom table approach may be your best bet.
>
> "The K-V version of post meta doesn't scale past a couple hundred
> million entries."
> If your site had that much data, neither approach would work very
> well. At that point, you could try caching, or figure out how to
> abstract postmeta to use other DBs (e.g. MongoDB).
>
> Matt
>
> On Nov 3, 11:07 pm, Caio Rogerio Ribeiro <caioroge... at gmail.com>
> wrote:
>> For article like content i'm scared to use anything but the core tools
>> (just plugins to deal with the creation of custom post types)
>>
>> No one knows how these plugins like pods and others cms plugins will
>> grow and can lead to big problems of incompatibility with future
>> features for example...
>>
>> The advantage on my view is to use features not suported by  WP like
>> homepages (panels in drupal for example)
>>
>> For who wants a good UI to deal with custom post types, taxonomies and
>> fields I recomend more types, more taxonomies and more fields plugins
>>
>> Enviado via iPhone
>>
>> Em 03/11/2011, às 22:50, IC IC <icwordpr... at gmail.com> escreveu:
>>
>> >http://wordpress.org/extend/plugins/pods/
>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hack... at lists.automattic.comhttp://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>