NYCPHP Meetup

[Brian Dailey]

I wonder what kind of a speed hit you would take in using this
technique. I've always thought that indexing a huge column would be a
bad idea. Still, I supposed you could store the "reportable"
information in a seperate column and filter out the extra stuff that,
while appearing in the report, isn't necessarily needed for searches.

I'm not using any PHP framework for this particular application (woe
is me), so I can't use Zends tools necessarily, but I will look more
into their approach and see if I can garner any useful techniques from
it.

Thanks for your input!

- Brian

Jon Baer wrote:
> So here has been my latest approach (or idea) ...
> 
> Since *normally* your main objective is to reach a result page (view) of 
> data, (either from a report or just a general link compiled from 
> criteria), I normally include @ least one column of YAML-based data (a 
> misc field of sorts).  Obviously this is based on what your doing but 
> its a general idea.
> 
> Then from that data and any other indexed columns on your schema build 
> an index using Zend Framework / Ferret / Lucene and interface the YAML 
> w/ that data.
> 
> I normally take this approach when Ive labelled a situation "client 
> can't figure out what data he really wants yet".
> 
> I think you have to think outside the box and have knowledge or querying 
> the index ...
> http://framework.zend.com/manual/en/zend.search.query-api.html
> 
> But once you apply behaviors to objects (and ultimately forms) like 
> "this object is searchable via x, y, and z" it makes managing it easier.
> 
> My opinion on the idea of microsearching your data and being flexible.
> 
> - Jon
> 
> On May 15, 2007, at 10:45 AM, Brian Dailey wrote:
> 
>>
>> I have several large forms that I am putting together. I'm aiming to 
>> keep them flexible and make it fit within the database object schema 
>> that I have used so far in this particular program.
>>
>> In the past with a large form I've seen some developers resort to 
>> tables with a multitude of columns... I thought that this was a kludgy 
>> solution and I'd like to avoid it if possible. Another way I've seen 
>> it handled is to have a header table and a detail table that works 
>> something like this:
>>
>> table: documents (id, date, etc)
>> table: documentdetails (documentid, fieldname, fieldvalue)
>>
>> All of the form values were stored in a fieldname=fieldvalue format 
>> inside the table. This worked nicely until you attempted to run 
>> reports on it - you couldn't easily combine data since it all existed 
>> in different table rows.
>>
>> So, I humbly come before thee, o PHP gurus, and ask you, how would you 
>> advise approaching this? Are there other ways to handle huge forms? I 
>> have seen people serialize arrays and store them in a column, but I 
>> can't see that working well when creating reports.
>>
>> I've googled and read around as much as I can on this one, but what I 
>> need is some advice from some more experienced developers. Opinions?
>>
>> -- 
>>
>> Thanks!
>> - Brian Dailey
>> Software Developer
>> New York, NY
>> www.dailytechnology.net
>> <support.vcf>
>> _______________________________________________
>> New York PHP Community Talk Mailing List
>> http://lists.nyphp.org/mailman/listinfo/talk
>>
>> NYPHPCon 2006 Presentations Online
>> http://www.nyphpcon.com
>>
>> Show Your Participation in New York PHP
>> http://www.nyphp.org/show_participation.php
> 
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
> 
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
> 
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
> 
> 

-- 

Thanks!
- Brian Dailey
Software Developer
New York, NY
www.dailytechnology.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: support.vcf
Type: text/x-vcard
Size: 264 bytes
Desc: not available
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070515/91587183/attachment.vcf>