Hello, I'm having problem with databa schema. Assignment document contains list of fields, but I'm not sure about fields order - can I rely on assignment document and access fields in this manner: String[name_index], where name_index = 0 is constant? I'm talking about complex meta-data approaches, I'm just curious if somebody was able to pass with hardcoded constants instead of database file header schema based approach? While database schema approach is more flexible, it requires either to expose database schema information to gui tier or wrap schema into business level proxy/adapter.
hi Gytis As far as I know, there are some people passed with hard coded field names. However, IMO it is not a good software design. If you hard code the field names and position within a record, then your program is bound to this database only, and cann't be reused if the database is modified. which defeats the purpose of OOP. Reading the schema dynamicaly, and customizing the software to accommodate the new database file is the approach I used designing my project. I used what you called it proxy/adaptore for the metadata. However, I am not done with the project yet. I have just finished the data access layer, and I am going to start on GUI sometime soon. So, I don't know how dificult or easy it will be. good luck
SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle
Joined: Feb 02, 2004
Hanna, I totally agree with you that hardcoding record structure is not the perfect solution. But could we take a look at the requirements: there is no requirement to respond to database format changes, but there are notes that system will not be reused in future and is for learning purposes mainly. Now just imagine junior programmer, looking at those meta-data trikcs - he/she will be confused, I guess. One more note - how many applications you have wrote, which respond to underlying database changes? None for 99% from all cases, I guess.