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
begin:vcard
fn:Brian Dailey
n:Dailey;Brian
org:;Department of Geekery
adr;dom:;;;New York;NY
email;internet:[EMAIL PROTECTED]
title:Senior Software Engineer
tel;home:423 506 0349
x-mozilla-html:FALSE
url:http://dailytechnology.net
version:2.1
end:vcard
_______________________________________________
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