deXterche
тадаммм
- Член од
- 12 февруари 2006
- Мислења
- 4.920
- Поени од реакции
- 941
Еден од клучние делови при градење на софтверска апликација е изборот на база на податоци. Како ја избирате базата? По кој критериуми? Што практикувате најчесто?
Многу фактори зависат за тоа која база треба да се користи како најбитни би ги издвоил: платформата на која работиме, колкава ќе биде оптеретеноста на базата, колку е способен тимот на девелопери кои ќе работи на проектот, дали сме спремни да плаќаме лиценца или ќе користиме некоја фрее верзија на дата база и уште пар други битни работи кои понатака ќе не донесат до правилното решение за избор на база на податоци.
Најдов една интересна статија на нет, за тоа како да одберебе дата база, би сакал да ја спооделам со вас па да подискутираме малце околу правилниот избор на базата на податоци, како ја правите вие таа селекција и кои се факторите кои влијаат на вашиот избор
Многу фактори зависат за тоа која база треба да се користи како најбитни би ги издвоил: платформата на која работиме, колкава ќе биде оптеретеноста на базата, колку е способен тимот на девелопери кои ќе работи на проектот, дали сме спремни да плаќаме лиценца или ќе користиме некоја фрее верзија на дата база и уште пар други битни работи кои понатака ќе не донесат до правилното решение за избор на база на податоци.
Најдов една интересна статија на нет, за тоа како да одберебе дата база, би сакал да ја спооделам со вас па да подискутираме малце околу правилниот избор на базата на податоци, како ја правите вие таа селекција и кои се факторите кои влијаат на вашиот избор
http://www.ibm.com/ напиша:Choosing a database management system
A resource for the developer without a data management black belt
Anyone looking for a good flame war can always drop into any software development forum and casually ask what database software should be used for the next project, or even ask whether he or she needs to bother with a relational database. Because databases technologies are such an important part of programmer philosophy, it is hard to find objective discussion for the hapless developer looking for a good, general-purpose database management system (DBMS) to use in a project. How does one choose between the relative features of different DBMSes? What sorts strengths and weaknesses of various products can one anticipate products? This article tries to discuss some of these matters on even ground.
The study of databases is a battleground of ideas. The database community is one of the oldest in the computer world, and it is almost as famous as the application programming community for the diversity of its ideas and the sharpness of the debates between its gurus. Lately events have conspired to expose these concerns to a wider audience. For instance, the seemingly inexhaustible march of the Web revolution has exposed more and more developers to database issues because of the desire for ever more dynamic Web sites. And the crown prince of Web technologies, XML, has had the effect of increasing awareness of data design in general.
This means that more and more developers find themselves choosing between database management systems (DBMSes). This can be a daunting choice considering the many available DBMSes, both open and closed source, and the broad spectrum of differences between them. This article provides some guidance through the maze of available DBMS features and methodologies, to help the developer quickly narrow the choices to the best candidate.
Note that no DBMSes are mentioned by name. There are many resource that provide the feature sets of particular offerings. This article focuses on the general technologies, and hopefully also gains the advantage of minimizing bias towards any particular package.
Models
Probably the most fundamental choice to make in the DBMS hierarchy is the model used to store, manage, and query databases. Besides affecting what software you need to acquire, this affects the very way you will think about the data, and can be a surprisingly hard choice to undo later on. Note that as I keep the discussion to database models that are in significant current use; this is not meant to be a comprehensive survey of DBMS methodologies through history since some significant models, such as network databases, have been omitted because of a lack of modern tools and practice.
Ad-hoc databases
The earliest databases were merely ordered aggregations of raw data, which one could call an ad-hoc database. They are not stored so as to optimize storage or queries (a query is a request for database records that conform to a given pattern), but are usually designed to be read in as a whole by the application (although there have been "random access" ad hoc database systems). Ad hoc databases are still used quite often. From address books that are merely sequences of the address information in files, to the bulk e-mail lists most notoriously used by spammers, these are most useful when you have fully anticipated the use of the represented data and you are certain that more efficient or query-friendly formats won't ever be necessary. In this case, you needn't read much further. Your DBMS is encoded in the standard library of your favorite language: fwrite for C users, BufferedFileStream for Java users, etc. Ad-hoc databases are very efficient and convenient if all the data is of low volume, is typically accessed together by an application, and a single application at that (that is, there is not much current or future need for sharing the data between applications). However, they become very unwieldy, inefficient and unmanageable once they grow beyond the size of available memory, as access patterns change, and if they need to be shared between applications.
Hash-based databases
Early algorithm specialists were quick to attack the problem of inefficient queries by coming up with systems for creating hashes of data records, which are compact keys that uniquely identify the record. Hashes are easy to manage and with a key, one can rapidly retrieve the entire record. Hash-based DBMSes, which use these techniques, are quite popular because of their simplicity and the fact that they come for free with most UNIX systems. They are very fast, and almost every programming language provides APIs for their access, but they tend to be quite bare on features. They are very well-suited to situations where an application wants to pluck records one at a time from the database, using a well-defined key. An example is for user profiles and authentication; where the application looks up a record by user ID, does its thing with the data, and moves on. They are less well suited to situations where records need to be cross-referenced, or the information in the records needs to be sliced and diced in some clever way.
Hierarchical databases
An early development in DBMS was to organize information into regular records containing other regular records in a more structured way. These are known as hierarchical databases and have enjoyed a bit of a revival with XML's popularity, because XML has a general hierarchical structure. Hierarchical databases can be quite suitable for data such as purchase histories that consist of tightly coupled records of information, for example, customer information to purchases made to support calls placed. The problem with hierarchical databases is that they have a way of accumulating redundant data (which was one of the main claims of relational databases in their battle to wrest dominance from hierarchical databases in the '70s). Another problem is that they can be hard to query flexibly in ways that go against the tight coupling of the data hierarchies.
Relational databases
Relational databases are, of course, the current king of the hill in database technologies. This doesn't mean that more data is kept in relational databases than any other model, but rather that when one goes about asking about what the "real" database model of choice is, he or she is most likely to be told to get relational religion. There is some good reason for this. Relational databases are wonderful for discouraging redundant data and for the speed of complex queries; they also have a huge number of tools and APIs to support them. They are best used in situations where a lot of records are being combined and cross-referenced to synthesize results. An example might be the production data of a manufacturing firm, where information about inventory, part specifications, personnel availability, costs, sales and supplies need to be thoroughly analyzed in order to make production decisions. However, like any power tool, they can be quite dangerous. Relational DBMSes (RDBMS) are designed to model very highly structured data which has been modeled with mathematical precision. If one's database design is not up to snuff, not only might the advantages of the relational model be lost, but the result can actually be worse for maintainability than with less stringent models. If you do opt for relational databases, be sure you understand concepts such as normalization and referential integrity. These days, almost every RDBMS uses the Structured Query Language (SQL) for description and querying of the records.
Object databases
Object databases emerged as a way to translate the techniques of object-oriented programming to data storage models. The data are organized as distinct objects, each of which belongs to a class, which might use inheritance to acquire aspects of other classes. Each object can have a set of attributes of simple types such as integer and string, and relationships to other objects. As you can imagine, they provide a very natural API for access using object-oriented languages such as C++, Java and Python. Object databases can be a great choice for this reason, but it can also seduce programmers into poor data design: techniques that make sense when the data lives in memory can be very slow and resource-intensive when the data is stored on disk.
Semi-structured databases
The emergence of XML has enlivened another corner of database modeling: semi-structured databases. As RDBMS took over the universe, many developers lamented that their rigorousness made them unsuitable for modeling data designed directly for human consumption, that is, more loosely organized records including structured documents and systems that made it easy to make changes in the model. Efforts to provide DBMSes that accommodated such "semi-structured" data thrived in academia until XML took them to the mainstream. Most XML formats define semi-structured data, and so XML -- whether directly stored in files or in an XML repository -- provide a great deal of flexibility, especially in Web-based systems where the documents are as important as the structured records. The main drawback is lack of efficiency. The data typically take up much more of the available resources than with other database models, and queries can be slow and cumbersome to set up. Semi-structured databases are very strong where documents and more structured data coexist, such as Intranets and Web-based applications.
продолжува...