• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Database modeling problem...

 
Julien Martin
Ranch Hand
Posts: 384
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I am faced with a database modeling problem which is as follows:

I am designing the web site for a sculptor and I have a sculpture table that contains several sculptures (width, height, depth, title, description) each sculpture tuple/row has several photos hence another table: the photo table and so on.

The problem is with what I call "residual" information such as these:
-sculptor's several email addresses
-sculptor's several phone numbers
-sculptor's address (made up of street, postcode, country)
-sculptor's biography (probably a longtext)
-sculptor's several photos

You see from above that there is only one sculptor. Had there been several scultors in the domain model, I would have gone ahead and created a sculptor table but there is only one and there will never be more than one. It wouldn't make sense to have a table with one line only.

How then should I structure/model the above information?

Thanks in advance,

Julien Martin.

PS. Some of this information is subject to frequent changes and therefore a properties file is not a good candidate.
 
Zemian Deng
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Julien,

From what I read of you information, each scriptor should have zero of more scriptures right? and you are working on a app that runs by only ONE scriptor.

Despite this, if you have full control on table, you should go ahead and create a scriptor table and have it's information there, and then link it's ID to each scripture rows. It should help you model and relate data better.

If you don't like that, then you can always just create a simple POJO Scriptor class that capture all that information, and have it loaded at startup of your application (use ApplicationContext for webapp). If you need this information change and persist during the live of application run, then you need provide form and a way to store it anyway. So you might as well use the db.

-Z
[ August 08, 2008: Message edited by: Zemian Deng ]
 
Julien Martin
Ranch Hand
Posts: 384
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for replying,

only ONE scriptor.

right.

Despite this, if you have full control on table, you should go ahead and create a scriptor table and have it's information there, and then link it's ID to each scripture rows. It should help you model and relate data better.

I would then have a table with only one row in it?

Julien.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It wouldn't make sense to have a table with one line only.


This statement doesn't make much sense, in my opinion. A relational table is a storage bin for electronic records. One record, ten records, or a hundred thousand. The number of records that may be stored in a table should not have any influence on the design. Key factors of relational table design are specified in the rules for 1NF, 2NF, 3NF and BCNF.
 
Julien Martin
Ranch Hand
Posts: 384
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all,
I think I am going to go ahead and have a single row table.
Julien.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic