This week's book giveaway is in the Features new in Java 9 forum.
We're giving away four copies of Java 9 Revealed and have Kishori Sharan on-line!
See this thread for details.
Win a copy of Java 9 Revealed this week in the Features new in Java 9 forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

NX: flexibility of database definition  RSS feed

james airey
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have written some code to analyse the header of the database file and determine the name and size of all the fields, and then read them into some database objects.
I'm now wondering if there was any point in doing that.
Does anyone have any feedback on whether Sun likes us to read the file at run time versus hard coding it (or even placing the definition in a config file)?
Andrew Monkhouse
author and jackaroo
Marshal Commander
Posts: 12100
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi James,
I believe this was discussed in a very recent post. One person commented that it might be nice to use the values you read from the data file as your column headings, then use the descriptive name that you get in the instructions as a tool tip. That way you get the benefit of a short displayed name but still have the full descriptive name.
Personally I like the idea of reading (and using) the values from the database. That way, if anyone decides to enlarge a field; or change the order of the fields; or add a field; or ... then your application will still work.
But I don't have a definitive answer on what Sun are looking for.
Regards, Andrew
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know what Sun wants either. At the very minimum, the header information
would have to be hard coded as constants within the program. But, it's not much
harder to read the header and use that information to read any data file falling
within the general schema.
I look at this project from the standpoint that I might actually want to use the
software I create myself. So, it's not hard to imagine either adding a new
field, changing the length of a particular field or fields, and even adding
a completely different table (let's say, because I might want to record names
and addresses of museums for personal use). Although it is easy enough
to recompile, the program becomes more useful for future growth if it
can read one or more files following the general schema. Again, I have
no idea what Sun expects, and it's quite likely that in a real world environment
with time pressure, that I might hard code the values; but, if there was
time later, I'd go back and read the header information dynamically and use it.
Since there is no time limit, and reading the header information makes the
program more useful, and reading the header information poses problems
which I find interesting (for instance, although my program most
probably will not have this bell and whistle, you can imagine a general program where
it reads the header information, and the user can dynamically select which fields to
search), I'm going to at least read the header information so that my program
will work under the following conditions: as long as the given Sun search
fields are the same field numbers within the record, then if any field length
changes, and any field is subtracted or added to the record,
my program will always be able to extract the data from the input file and
display it in a reasonable manner to the user.
Javini Javono
Philippe Maquet
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini,
All good points IMO.
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!