File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: Is the following design choice ok in your opinion? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S: Is the following design choice ok in your opinion?" Watch "B&S: Is the following design choice ok in your opinion?" New topic

B&S: Is the following design choice ok in your opinion?

Lek Olof

Joined: Jan 03, 2007
Posts: 10
I want to make the choice that skip reading the magic cookievalue and the schema description part and just assume I have one table with the specified fields and field lengths and that these will never change in name or size.

This way the reading part would be much easier but then I would lose the option to rename fields and sizes in the schema part. For those who is building up the databse dynamically according to the schema part the solution has more advantage but I want to keep the solution simple as possible,

do you lose points if you disregard the schema information?

Rudolph Jen
Ranch Hand

Joined: Nov 17, 2006
Posts: 37
Hi there.

I do not totally understand your question. You have to design and develop an application that handles the information from the db-file for the users. These information are only the records with content.

Your Implementation of the DataAccess of course needs to know the schema (field lengths,..) to select the required record for the user correctly.

I use for example a DbFileChecker at startup, to quarantine that the supplied db-File is a valid one. But in runtime I will always skip all the magicCode, number of fields, fieldName, length, because I would like to get the real stuff.

Hope that helps

Regards R

SCJP<br />SCJD (in progress)
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918


I think you mix two concepts here.
1.The magic Cookie - it helps you to identify the right database file
2.the meta data information / handling

You are free to hardcode (but I don't recommend this) or to build an dynamic model for the meta information (here I mean fields, fields size, field order, etc) as long as you justify your decisions.
The mg. is used to identify the right database file if you skip it you may fail during reading(because the database follows an other scheme) you you can permanently damage an existent db (just by adding a record with a wrong format).

Regards M

I agree. Here's the link:
subject: B&S: Is the following design choice ok in your opinion?
It's not a secret anymore!