What is your backend?

Question

How do you stored records of your programs, do you use MS Access, SQL server or what?
Other programs do not use this backend software, what do you think, how other program stored their records?

Is it possible to encrypt the MS Access database?

Answer 1

BackEnd is where we store the information. Every program that stores data must be using one of the following : MS Access, SQL Server, Oracle, dBase III, FoxPro, DB2, XML, Excel, MYSQL.
Many of them are table based databases, while others are file based databases. XML is tag based database used to store records. Excel is cell based.

Answer 2

I use MySQL for various php programs (such as gallery2, phpbb2) as well as various "eggdrop" bots, and a couple other things.

other backends that i have used for personal scripts that don't need the functionality of a sql server are "hash files"
I've even used variables alone as "backends" for non-sensitive and temporary data.

Answer 3

Database Types

A lot of the sites that we visit on the web today are generated by a script of some description, and a great deal of them will use a database in one form or another. Like it or loathe it, building pages dynamically from databases is a technique that is here to stay.

There are two main types of database; flat-file and relational. Which is the best one to use for a particular job will depend on factors such as the type and the amount of data to be processed; not to mention how frequently it will be used.
Flat-File

The flat-file style of database are ideal for small amounts of data that needs to be human readable or edited by hand. Essentially all they are made up of is a set of strings in one or more files that can be parsed to get the information they store; great for storing simple lists and data values, but can get complicated when you try to replicate more complex data structures. That's not to say that it is impossible to store complex data in a flat-file database; just that doing so can be more costly in time and processing power compared to a relational database. The methods used for storing the more complex data types, are also likely to render the file unreadable and un-editable to anyone looking after the database.

The typical flat-file database is split up using a common delimiter. If the data is simple enough, this could be a comma, but more complex strings are usually split up using tabs, new lines or a combination of characters not likely to be found in the record itself.

One of the main problems with using flat files for even a semi-active database is the fact that it is very prone to corruption. There is no inherent locking mechanism that detects when a file is being used or modified, and so this has to be done on the script level. Even if care is taken to lock and unlock the file on each access, a busy script can cause a "race condition" and it is possible for a file to be wiped clean by two or more processes that are fighting for the lock; the timing of your file locks will become more and more important as a site gets busy.
Database Management (DBM)

The Database Management Layer allows script programmers to store information as a pair of strings; a key, which is used to find the associated value. Essentially, a DBM adds more functionality and better sortation during storage to the binary flat-files that it uses. There are several versions of DBMs available, but the most popular is the Berkley Database Manager; also known as the Berkley DB.

The Berkley DB is an improvement over normal flat-files, as it provides a way for programmers to use the database without having to worry about how the data is stored or how to retrieve the values. Retrieval of data using the Berkley DB is often much faster than from a flat-file, with the time savings being made by storing data in a way that speeds up the locating of a specific key-value pair.

Creating, editing and deleting data when using the Berkley DB is actually quite simple; once the database has been tied to the script you just use and manipulate the variables as normal. The problem of file locking that plagues flat-file databases is still apparent when using DBM, so you should still take care when planning scripts that utilize it.

The relational databases such as MySQL, Microsoft SQL Server and Oracle, have a much more logical structure in the way that it stores data. Tables can be used to represent real world objects, with each field acting like an attribute. For example, a table called books could have the columns title, author and ISBN, which describe the details of each book where each row in the table is a new book.

The "relation" comes from the fact that the tables can be linked to each other, for example the author of a book could be cross-referenced with the authors table (assuming there was one) to provide more information about the author. These kind of relations can be quite complex in nature, and would be hard to replicate in the standard flat-file format.

One major advantage of the relational model is that, if a database is designed efficiently, there should be no duplication of any data; helping to maintain database integrity. This can also represent a huge saving in file size, which is important when dealing with large volumes of data. Having said that, joining large tables to each other to get the data required for a query can be quite heavy on the processor; so in some cases, particularly when data is read only, it can be beneficial to have some duplicate data in a relational database.

Relational databases also have functions "built in" that help them to retrieve, sort and edit the data in many different ways. These functions save script designers from having to worry about filtering out the results that they get, and so can go quite some way to speeding up the development and production of web applications.
Database Comparisons

In most cases, you would want your database to support various types of relations; such databases, particularly if designed correctly, can dramatically improve the speed of data retrieval as well as being easier to maintain. Ideally, you will want to avoid the replication of data within a database to keep a high level of integrity, otherwise changes to one field will have to be made manually to those that are related.

While several flat-files can be combined in such a way as to be able to emulate some of the behaviours of a relational database, it can prove to be slower in practice. A single connection to a relational database can access all the tables within that database; whereas a flat file implementation of the same data would result in a new file open operation for each table.

All the sorting for flat-file databases need to be done at the script level. Relational databases have functions that can sort and filter the data so the results that are sent to the script are pretty much what you need to work with. It is often quicker to sort the results before they are returned to the script than to have them sorted via a script, few scripting languages are designed to filter data effectively and so the more functions a database supports, the less work a script has to do.

If you are only working with a small amount of data that is rarely updated then a full blown relational database solution can be considered overkill. Flat-file databases are not as scaleable as the relational model, so if you are looking for a suitable database for more frequent and heavy use then a relational database is probably more suitable.

As i'm using Relation DATABASE (Oracle 9i on Unix)

Answer 4

Linux uses MYSQL

Answer 5

my butt