tags:

views:

58

answers:

2

Hi All,

As I am working on Employee Management system, I have two table (for example) in database as given below.

EmployeeMaster (DB table structure)

EmployeeID (PK) | EmployeeName | City

MonthMaster (DB table structure)

Month | Year | EmployeeID (FK) | PrenentDays | BasicSalary

Now my question is, I want to store data in file system rather than storing data in SQL or ORACLE.

I want my data in file system storage for Insert, Edit and Delete opration with keeping relation with objects too.

I am a C# developer, Could anybody have thoughts or idea on it. (To store data in file system with keeping relations between them)

Thanks in advance.

Any ideas on it?

+3  A: 

If you are wanting to perform EDIT/DELETE operations, then don't do this. You will only end up recreating a database from scratch, so you might as well just use one. If you won't want to use SQLServer or Oracle, then use mysql, postgresql, or any of the various in-memory (persist-to-disk) databases out there. If you need to maintain human-readable, or plain/text based data-files, then still use an in-memory database, and save as .csv when persisting to disk.

Using external files can work well if you are doing batch processing, and focusing on APPEND operations only—I do this regularly, and achieve throughput that is simply impossible with a relational database.

You can also use the filesystem effectively if you use one file per record, and your operations are restricted to MAP/INSERT/DELETE/REPLACE; and, never attempt UPDATE. But again, if I need to do updates or correlations, or any of a number of other interesting queries I use a database.

Finally, you can use the filesystem if your operations are DUMP/RESTORE from in memory datastructures to a single file. In which case you should use whatever the standard XML persistence library is for your platform and just perform a RESTORE when you start the application, and a DUMP on exit or periodic save. Pretty much as soon as you move to multiple files you should be looking at a database and ORM again.

Ultimately, unless you are dealing with a very small amount of data; or you are dealing with a large amount of data (at least 100's of millions of records), stick with a database.

Recurse
+2  A: 

You could use SQLite which is basically a "lightweight" DBMS hosted as a DLL in your process.
That would work well for you, if data format doesn't have to be human-readable and if concurrent data access (by several processes at once) is not required.

VladV