Re: tricky database design

Daniel Talsky wrote:
> Thanks for your help, Alan, let me explain a little further:
>
>
>>To me it makes sense to order the assoication, since your stuff won't be
>>ordered until you group it together on a page.
>>
>>I don't see how the table ordering brings things together, some references
>>clauses might help. When you mean table, do you mean table as HTML table? Like
>>if you want to order a list of pages in a table of contents:
>

> The table field in the ordering table is meant to refer to a database
> table. I have an HTML page, and it wants to have some elements from
> the "heading" table and some from the "copy" table, and be able to use
> them interchangably.
>
> So lines in the ordering table would look like this:
>
> table_name id_ref page_ref sequence_order
> ---------- ------ -------- --------------
> heading 233 42 1
> copy 16 86 4
> copy 403 22 1

I think you want to have both copy and headings on a page, and you want them ordered, and you thinking that you can use the table name as type information.

That last is a no go as Mr Kaas noted. Table and column names as data indicates you're not quite with the relational program yet.

Niether am I, but am a bit further along, so I ask myself these questions:

Will headings or copy appear on more than one page?

• Is this what the order table is about, what goes where?

Can a piece of copy have more than one heading? Do headings ever exist without a piece of copy?

• You need to relate copy and heading somehow, if they don't really belong as columns in the same table. Are they separate so you can put headings on a front page, and over the copy on a detail page?

Isn't a heading really copy that is usually very terse?

• If you agree than heading is a property not an object, a column not a table.

Alan Gutierrez Received on Wed Jan 08 2003 - 16:34:31 CET