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

[Dagan Henderson]

> 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?

I'd have to look back at some code to be more specific, but there is a filter that can be used to add additional table columns to the search through OR statements. In other words, it's totally doable.

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Chris Taylor - stillbreathing.co.uk
Sent: Sunday, November 06, 2011 1:36 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] questioning the efficiency of using custom post types

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/li
>> stinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://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