suppose we have a table that maps Publication to the Locations of their headoffices. we can create a table in the database or create a property file and use it. which one is going to be faster. when should we resort to using the property files
This is impossible to answer without knowing a lot more about the situation. What kind of application is this - desktop or web app? How often do you expect the data to change? Will the application be used by more than a single user? How many data items will there be?
it will be a we application where i need to map Chapter to its Topics. And certainly Topics in a Chapter will not change too frequently. There might be occasional additions in newer editions..thats all. But yes there will be heavy traffic
Joined: Mar 22, 2005
A property file seems fine if, and only if, ...
- its contents are cached in memory (in other words, no file access for each request)
- you can live with each update to the file necessitating a web app restart
- whoever has to maintain the information is fine with editing such a file
If either of these is not true, go with a database.
I would have thought a database would maybe be more appropriate.
Joined: Aug 03, 2008
well although the property file does not confirm to the logical structuring as provided by the database some times it is difficult to digest by designers but then they are faster if used properly i think as suggested by dittmer although i am not willling to becaue they now seem to disturb by database design.
For what it's worth I have just had a similar issue the past couple of weeks.
I have a system that has a number of categories and sub-categories (in fact the are Continent, Country, Region, City, Department) the idea is for the usr to be able to select a Continent then a list of all available Countries would appear, then they can click on a Country and the Cities would appear, then under there various departments.
At first I thought about using a properties file as I felt it was unnessarcery load on a database for the user to bee hitting the database eachtime they click a category/sub-category etc.
Things worked fine for my test system, as there was only Europe, UK, London, Birmingham, Accounts, Development and a handful of other values in the property file.
However each property has 6 values (id*, cat_id, parent_id, label, uri, status), as I say for the test purpose it wasn't a problem, but when you find Europe having about 40 Countries, US haveing 50 States etc I soon found that the property file was completely unmanagable.
I changed to a DB with columns for each value, then simple SQLs liek [select * from locations where parent_id = X], and it became a lot easier to manage.
Also I have now created a simple easy to use Admin tool that allows a user to CRUD these values, where'as before the user had to open the property file and had full access to everything, which meant errors became easy to happen (C&P was the biggest issue with incorrect URIs etc).
So for me the database approach became the method of choice (MySql5.1)
Joined: Aug 03, 2008
thanks kieth for sharing your valuable experience. you are absolutely correct. i think you must jot down these points and they are worth putting up in a blog. i would like to add a few things. i feel we must use property files when the data is less. secondly a property file must not be used when you expect the data to be relational. for example if you expect he user to know the states in a country is fine, but what if you even want the user to be shown the ZIP CODES for various states now here Country ----relates to---->States----relates to---->ZIP CODES. although you may have two property files in such case but that would be a bad practice reason being if this data is put in the database we can fire a single statement query to know "the ZIP CODES for all the state whose name begin with H" but for doing the same through property files is a cumbersome task and it will certainly 1. Make the code complex 2. and slow