Re: [nyphp-talk] Flexible Forms & How to store them...

On 5/15/07, Brian Dailey <[EMAIL PROTECTED]> wrote: Which leads me to my next question - Chris, in your 2 layer approach how do you handle indexing? If you have a fairly sizable chunk of YAML/XML/etc data, how do you handle searching it? Well, I haven't had to. I've been working in content and

RE: [nyphp-talk] Flexible Forms & How to store them...

> [mailto:[EMAIL PROTECTED] On Behalf Of Patrick May > My question is -- when the forms change, who makes the > change? You, or a user via a tool? Though I'd offered a solution for EAV, I haven't gone that route in quite some time (usually only for dynamic surveying tools where the forms / fiel

Re: [nyphp-talk] Flexible Forms & How to store them...

Hello, 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 som

Re: [nyphp-talk] Flexible Forms & How to store them...

csnyder wrote: On 5/15/07, Jon Baer <[EMAIL PROTECTED]> wrote: This is really a 2 layer approach not using MySQL for FT indexing. Any other option gives you way more IR functions than MySQL does. Although it would be fair to point out that it is pluggable: (

Re: [nyphp-talk] Flexible Forms & How to store them...

I'm already looking at 100,000+ records, and I am somewhat nervous as to how it will perform as the load begins to get a little bit higher. I suppose I will have to do a little tweaking to make it work properly, but it seems like this approach would lend itself a little more to indexing rather

Re: [nyphp-talk] Flexible Forms & How to store them...

Brian Dailey wrote: This looks like what I'll ultimately be doing. I played around with some SQL queries and what I ended up with was similar to this - joining the table for each data value that I wanted to look up (and since I expect a matching data value, I don't even have to LEFT JOIN every

Re: [nyphp-talk] Flexible Forms & How to store them...

On 5/15/07, Jon Baer <[EMAIL PROTECTED]> wrote: This is really a 2 layer approach not using MySQL for FT indexing. Any other option gives you way more IR functions than MySQL does. Although it would be fair to point out that it is pluggable: (

Re: [nyphp-talk] Flexible Forms & How to store them...

Im not sure this does justice w/o any demo but Id never plan on doing a search like that ... the idea was that one field w/ key:value pairs would be split and put into a searchable index via Zend_Search ... http://framework.zend.com/manual/en/zend.search.html The query (or report) from the in

Re: [nyphp-talk] Flexible Forms & How to store them...

Brian Dailey wrote: This looks like what I'll ultimately be doing. I played around with some SQL queries and what I ended up with was similar to this - joining the table for each data value that I wanted to look up (and since I expect a matching data value, I don't even have to LEFT JOIN everyt

RE: [nyphp-talk] Flexible Forms & How to store them...

> What if a data record is missing some field values? Or has > more than one value stored for some field name? Interesting points... For missing data, you can make the field nullable... // set field_data to NULLABLE ALTER TABLE data_fields CHANGE field_data field_data VARCHAR( 100 ) NULL DEFA

Re: [nyphp-talk] Flexible Forms & How to store them...

This looks like what I'll ultimately be doing. I played around with some SQL queries and what I ended up with was similar to this - joining the table for each data value that I wanted to look up (and since I expect a matching data value, I don't even have to LEFT JOIN everything, which speeds i

Re: [nyphp-talk] Flexible Forms & How to store them...

On 5/15/07, Mark Armendariz <[EMAIL PROTECTED]> wrote: CREATE TABLE data_fields ( field_id MEDIUMINT(6) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, data_id TINYINT(3) UNSIGNED NOT NULL, field_name VARCHAR(20), field_data VARCHAR(100) ) Did you ever worry about

Re: [nyphp-talk] Flexible Forms & How to store them...

On 5/15/07, Jon Baer <[EMAIL PROTECTED]> wrote: I normally include @ least one column of YAML-based data (a misc field of sorts). At first I thought this would work with a MySQL FULLTEXT index, but of course it won't because the field names would be in more than 50% of the records and would th

RE: [nyphp-talk] Flexible Forms & How to store them...

> -Original Message- > [mailto:[EMAIL PROTECTED] On Behalf Of Brian Dailey > Sent: Tuesday, May 15, 2007 10:45 AM > 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: documentdetail

Re: [nyphp-talk] Flexible Forms & How to store them...

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

Re: [nyphp-talk] Flexible Forms & How to store them...

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

[nyphp-talk] Flexible Forms & How to store them...

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