Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

(URLyBird) Database Design

 
Robert McDonald
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm currently working on the database design and have just completed some of the functions in my FileDatabase class which performs the actual crud functions on the file.

I am debating about what to do with the metadata - i had hardcoded the values just to get things working but have now added a Metadata class which does the work of reading this from the file. Currently i have it as a singleton and this is called from the FileDatabase constructor.

Does this make sense or should it be incorporated into the FileDatabase class itself? My original thinking is that if e.g. a sql db was swapped in we might still need to read the metadata but the fact is that the metadata class is reading from the file so it is really a FileMetadata class and maybe should just be in the FileDatabase(thinking out loud here!!). Has anyone insight into a good way of using the Meta?

A second question is that i assume we are required to actually implement the create and delete methods? The requirements do not specifically call for this but i am assuming since we have to implement the methods in the interface that an empty implementation would be inadvisable. I'm cautious about going beyond the requirements but at the same time, if i was asked to do this in a real work situation i would definitely code and test these methods fully. (At the same time, a real life system would very likely need creation and deletion of records somewhere in it so it is difficult to compare).

Thanks
 
Ian Hamilton
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Robert,

re: Question 2 - From what I have read in this forum most people agree with your assumption that create() and delete() should be implemented fully i.e. coded and tested, even though they will never be called by the client.

re: Question 1 - I eagerly await the discussion of others because I am at a similar stage!

Ian
[ May 30, 2006: Message edited by: Ian Hamilton ]
 
Roy Mallard
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is a good idea to "hard code" the metadata as little as possible, and keep it in one place.

I have an URLyBirdFileParser class (implements FileParser) that contains all the formatting information/schema for the urlybird .db file format.
There is a parser for each field type, BooleanParser, DateParser etc. The URLyBirdFileParser class has a hashmap that lists the fields and associates each field with a parser. The FileParser has a getSchema() method that returns a list of NamedFields. (A NamedField contains a name string and a subclass of Field).

That way if the schema changes, for example another field is added, I only have to modify one line of code.

I have a Field interface that is implemented by BooleanField, CurrencyField etc. I also have some "viewer" classes to display Fields nicely. Fields are associated with viewers in a hashmap in the client view.

Hope that helps.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic