• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

What is the best way to handle this?

 
Ranch Hand
Posts: 387
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure what APIs/setup to use for this situation:

A company wants to store data projects they do for clients. Each year, the data fields are set (as a result of gov't requirements) and they won't change for any client project for that year. however, the fields required can (and usually do) change every year. So things they require this year, might not be needed the next year and new fields might be introduced.

While there are likely to be many common fields from year to year, there's no way to guarantee which ones will remain consistent. They also want to be able to do searches on the data and fields, for projects within a year and across years.

What's the best framework/API/configuration to handle this? EJB? Simple JDBC? If so, how should the database be handled? Won't it have to constantly create new fields in a table? Or is there another way to handle this?

What's the best way from a "clean design/architecture" standpoint?
[ November 09, 2005: Message edited by: Dan Bizman ]
 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Store the fields as properties of the project. Use a join table or foreign key in the fields table. You can have as many fields as you want for a given project, and you can still search through them.

each field entry is a key value pair. The company should standardize as much as possible on the key names.
 
Dan Bizman
Ranch Hand
Posts: 387
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I thought of that, but the performance isn't the best and neither is the design. What about an object database like db4o?
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dan Bizman:
I thought of that, but the performance isn't the best and neither is the design. What about an object database like db4o?



Can you think of a different way to do it? No matter what you mask over it with, underneath its going to break down to the same thing. I also fail to see your problem with the design? Map seems a perfect match for what you are doing.
 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I thought of that, but the performance isn't the best and neither is the design.


I have used this design on a productive system and it worked well. The customer was very happy and due to it's flexibility the same db schema and application was used for further projects with some minor cosmetic changes. Consider that although you may lose a little performance in having this design, you gain huge amounts in flexibility.

Steve
[ November 10, 2005: Message edited by: Steve McCann ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic