Hi, In B&S assignment, I think that I have found some redundant information and I do not know which choice I should take :
Database schema section describes the field names and their corresponding lengths.
But the same information is included in Data File Format chapter Schema description section. [B]
If I use directly the static information from [B]Database schema , the other information will be redundant.
I believe that the more general approach will be to use the Schema description section which is included in the database file, and to dynamically read and interpret the field names and lengths, but this will make things a bit more complicated.
1. Hardcode the fields and maximum field length into your code. 2. Read the database file to determine the fields and the field lengths. 3. Do both, and verify they match.
Advantages:
1. Simple design 2. Future flexability, but the company is not willing to change the format of the databse file becuase the old apps still need to use it, so this is not a real issue, but it would be nice to have.
I have continued with coding and I realized that I need anyway the meaning of the fields, I'm sure that some "find" methods will need to know which one is the "name" field , for example. So, is no redundancy in the Sun description. And, as you say, the third version is the best.
I have chosen to make the server flexible and to make the client field-specific. So my server reads the db scheme (field names, field lengths, order...) from the schema description in the database file. If a field is added or removed from the schema, this is no problem for my server. I haven't done much coding for the client yet, but the client, and more specifically the gui, will be field-specific. That means that I will eventually hard-code the field names etc. I don't want to build a generic gui because I'm afraid this will introduce unnessecary complexity and probably compromise user-friendlyness. Amounts are displayed differently from company names etc. In the case of a db change, the client will have to be revised.
I am still in thinking/designing phase but I lean towards solution where server services operate rather on wrapper objects than String[]. Client does not have to care about position of "name" field, it simply calls getName() on wrapper object.
This of course does not solve problem of fixed/dynamic database schema.
I like 1st solution described by Samuel above. Anyway you have to fix something: hardcode in your code or on "general considerations" level saying that "bookable filed is last one in record" or "field names do not change in database even if db file defines them" etc.
I also think that the Data Scheme must be database dependent, at least like this is in my assignment. But I also I don't think that is to wise to hard code it but if you have arguments for this why not. I think that sun do this(incomplete/inconsistent specs) with purpose to let us to take some (god/not so god) decisions.
Regards M
Post by:autobot
Something about .... going for a swim. With this tiny ad ...
a bit of art, as a gift, the permaculture playing cards