PDA

View Full Version : Analyze this! Implementing new data with M:1 relationship to existing data.


RadarBob
08-30-2002, 05:04 PM
All;
I’d like some analysis of my idea for a major change I need to make to our existing web-based database program. I’m not versed enough in ASP, et.al. to know for certain how best to solve the problem. I need to know if my ideas are practical; plus specific code snippits would be a help.

I need to add several fields that together constitute a single record that will end up on one table in our database – with appropriate keys for data relationships.

The biggest question is how best to build the client end; related of course is the server/ASP stuff that gets things into the database.

Basic Design
The presumption is that we are creating a new record from scratch. We are not doing an initial fetch from the database nor editing a pre-existing record.

The user needs to be able to enter any number of these new “sub-records” within the web page. In other words this new record has a many-to-one relationship to the other data entered on this same web page.

I’m thinking of a button that opens a child window – here is where new records are entered. This will keep all this code “off” of the main web page during that initial page load. Additionally these fields are not required entry so that’s another good reason to not load all that code unnecessarily. Anyway, add and edit as needed then clicking a “finished” button will transfer all the data to the main page and close the child page.

On the child page I’m thinking of an “add” button, that when pressed creates a new row of blank fields for the user to fill in. To delete an existing record, check a “delete” checkbox and click a “delete checked records” button and makes that row of fields disappear from the screen. The shopping cart at amazon.com comes to mind. How does the shopping cart remember what's in it?

The HTML Elements
Here’s the hard part. The record is a mix of text and Boolean fields (well pseudo-boolean in the database – ie single charaters “y” or “n”). What’s the best way to tackle this so all the various fields “stay together” for a single record (ie during ONSUBMIT for example).

My initial thought is a series of <select multiple …> that I keep in synch (ie keeping the indexing coordinated). But using a <select> for a field that rightly should be a checkbox seems clumsy to me.

Passing these multiple <select multiple> objects to the server is easy. I know how to do that.

OR

Build a javascript data structure (OK, “object”) that holds the fields. Can an array of these objects be kept in synch with a particular table row in HTML? In other words if I change the 3rd field of the 2nd record, how do I know which JS object is affected? Or is that moot because, well, let’s just redraw the page on every field edit; which will re-build the JS objects each time. Does this make sense?

How would I pass the set of JS objects to the server? Store them as a cookie? I’ve never used cookies; don’t know what’s possible here.

OR

Any other ideas?

The Server Side
I will use an object separate from the "main" command object that puts the rest of the data into the database.

I’ve had zero success in the past using recordsets to get a multi-value field of the Request.Form into the database. It just doesn’t work. I ended up using a command with parameters. I suspect recordsets are less than they appear. :confused:

TIA…

RadarBob
09-05-2002, 01:23 PM
Let me try to restate the problem:

Imagine an HTML data entry form. Now imagine a part of that form that repeats. This repeating sub-set is not a single field, like a <select>. It's a group of fields. The user needs to be able to fill out the form along with any number ( zero to many) of this sub-set. It's a classic 1:many data relationship.

From my readings of various ASP books - the complete lack of material on the subject, you'd think this has never even been thought of before!! My cynical side says the authors don't want to tell us the crippling limitations of HTML/ASP/ADO in handling fundamental data structure/relationships - stuff that real DBMS tools have been doing for decades!!

Anyway, My concept, so far, has all the data on one page. For this sub-set, I don't know how many "records" the user will enter. My business rules don't limit. So the user may enter none, he may enter ten. I don't envision the "main" data entry page initialized with 30 empty rows for the user to enter sub-set data. That's ugly, unelegant, clumsy, poor design. So I'm thinking use a separate page/window to enter data. When the user "saves" this child window, the data is transfered to the "main" page.

My quandry is how to implement this sub-set on the main page. The user needs to see the information and the computer needs to differentiate separate records (client and server) so they can be stuffed into the database.