Sample flat file database

Question

I would like to see some examples of simple flat file databases and how to access them through the data layer. I previously wrote and read from a flat file, but I never created a data layer that accessed data for the application using text files.

If possible, it would be nice to see a tutorial with a data layer that uses a simple, regular flat database. An example that stores custom business objects in XML and then loads them would be nice because XML is so popular and easy to use.

I would also appreciate any links to sites that discuss best practices regarding flat file database design, etc.

My goal is to have a solution for storing simple data on a user computer and not need any special software (for example, SQL Server, etc.) to extract data from where it is stored.

I know this is a very general question, but any advice that can point me in the right direction is welcome.

Answer 1

You may have slightly changed your definitions, understandable due to the large number of similar technologies around the world.

XML is not a flat file format (or flat file database), but from reading your goal, it sounds like you really want to be a stand-alone relational database, not an actual flat file.

Like others, I can highly recommend SQLite for this purpose. There are bindings for various platforms, .NET has System.Data.SQLite , which in a single file is both a database provider and an engine.

Two big advantages of using SQLite are that the actual database is completely self contained in a single file controlled by your application and that it supports the standard SQL DDL and DML commands (i.e. SELECT, INSERT, UPDATE, DELETE, CREATE DATABASE / TABLE etc.).

For one user application, SQLite is an excellent (one of the best) ways to store both application data and settings. Recently there has been a discourse that it can even support smaller multi-user applications.

However, Oracle, MySQL, SQL Server, etc. still definitely prefer multi-user applications (even small applications) if you have the ability to access the database / use server.

In addition, do not forget that the choice of database is not mutually exclusive.

You may have a multi-user application with a rich client interface installed on many users computers. The central database here really needs to be a multi-user db such as MySQL. But within the rich client interface, SQLIte is ideal for storing each user's settings or, possibly, for offline support when the database cannot be reached.

Answer 2

biggy is the one I used in the past. It saves as JSON in flatfiles and you can find it on Github

Answer 3

Text formats such as CSV , INI , XML can be used to store structured data, but IMOs are not flexible or efficient for use as databases.

I recommend SQLite as a great alternative. It is a very powerful, lightweight, and standalone database engine.

Answer 4

You can get your cake and eat it:

SQLite is an SQL database that consists of a single file and does not require installation, has bindings for many languages ​​and works on various platforms.

It is not necessary if you mention writing your own data layer on top of flat files. In fact, if you do not want training, I would advise against this.

Answer 5

There are several built-in databases that your user does not have to worry about at all.

SQLLite is common, popular, cross-platform, etc. Depends on your implementation language. If you use Java, there are several, for example, Derby..NET is not my ballistic, but I assume that there is something there. At a minimum, MS has a free desktop, a built-in SQL engine that you can use.

Writing your own can be an interesting exercise, but this wheel has been made, and it’s just easier and more efficient to use the existing database than to start from scratch. This will not affect your users, therefore, if this is the main driver, there is no reason not to use an available product / project.

Answer 6

Perl has a DBD :: CSV module that can load csv files and query them using SQL statements. But for your purpose, I think you'd better explore SQLite , which is a proper relational database that runs without a server.

Answer 7

Instead of re-creating the databases, why not link your application with a simple database engine? Databases are of different sizes, not all are huge :-)

If you want to invent the wheel by looking at the source code for simple open source database engines, you should point you in the right direction.

Answer 8

I agree with many comments suggesting that it is better to use the existing database engine. However, as an attempt to answer the question:

• An extremely common flat file database format is Xbase (files usually with .dbf extensions). You can google for "xbase" and "dbf" and find a lot of information and any number of drivers. You should be able to extract some tips and advice if you are really interested.
• If you want to play with one, which is very likely on your system, you can use the ODBC "Microsoft Text Driver". If you have any material for accessing Microsoft data on your computer, you probably have this driver. I do not know for sure, but it is probably installed with MDAC. This driver will read and write comma delimited text files (among other formats).