Often meeting questions at designing a DB

There is a set of "tea" textbooks where it is in detail chewed as by means of masters to create tables, forms, reports (though masters just and do not use "plotters") – but fall or leight some important points are mentioned, the inattention to which can create serious problems, down to cardinal processing the project and carry of data ( "assembly" of tables, editing of modules, forms, reports, etc.). We shall consider(examine) some of them.

1. Agreements on names of fields, elements of management and objects

1.1. Blanks in names

Here the general rules (according to Help) which it is necessary to adhere:

• The name should contain no more than 64 signs
• The name can include any combination of letters, figures, blanks and special signs except for a point (.), an exclamation mark (!), a sign (`) and square brackets ([ ])
• Should not begin with a sign on a blank
• Should not include operating signs (with codes ASCII from 0 up to 31)
• Should not include direct inverted commas (") in names of tables, representations and the kept procedures in project Microsoft Access

The matter is that if with names it is supposed to work by means of procedures VBA in some cases will be problematic enough to address to a name of object if it contains blanks. For example, at the reference to a name with a blank, it needs to be concluded in square brackets that is not absolutely convenient. But in some expressions of a bracket are not admissible. As a result it is necessary to rename object, that often entails greater(big) problems with work of the program, or to search for " roundabout ways ». Therefore, it is better to choose one of variants:

ObjectName
Object_Name

1.2. Cyrillics or a Latin?

One more often discussed question: national symbolics in names of objects. The basic problem with which it is possible to collide at its use:

The program in which for the name of objects national symbols are used, WILL NOT WORK in system in which there is no support of this language

Especially it concerns cyrillics (the Russian alphabet). For this reason developers, who should work on different versions of office (and the more so abroad) insist on use of English names. However, sometimes only one replacements of symbols happens not enough – that the appendix of 100 % worked in the English version, it should be created in the ENGLISH VERSION of office. Besides use of cyrillics creates problems:

• At use of foreign utilities – they can not work with Russian names of objects. But even « with the » functions can be a problem. Try to create, for example, function in the module of the form, and to cause it, having registered in properties of the form on what or its event =My_Function (). Access it "will not see". Though if to address to the same function in a code of the module – all works. It speaks that full russification is not present
• Constant switching of an allocation of the keyboard. It causes irritation in many
• If you plan to work abroad (or with English versions of programs) it is meaningful to accustom itself to the standard standard designation of names of objects

Having read through the aforesaid, the impression is made, that on a question how to name objects of a DB, the answer is obvious, however not all so is simple. For the beginning we shall look at neighbours

Who worked abroad, that knows, that Germans practically always name objects in German, and the Frenchmen on is French, etc., and in general Europeans in this sense not disciplin (as, however, and all the others). So, if it is possible for them, why it is impossible for us? Though it is certainly easier – at them the latin alphabet. Well and if it is serious, use of national names has also the advantages:

• It is less than chances to name something so, that then will cause laughter in the native speaker ( and any which were more less knowing English)
• Much more quickly visually the inquiry or the table among hundreds by it similar is searched, the sense of the forgotten expressions, inquiries, etc. much more quickly is understood

Though such arguments will seem « not serious to " supporters « English school » (it will be got used, at the same time and English will learn), but, nevertheless, sometimes it is enough of it to pass to national designations, especially, if is not planned to use the program on other language versions of office.

1.3. Own system of designations

Having understood with the alphabet, we shall pass now to names. Here key rules on which developers converge all:

• Name objects of a DB, using the intelligent names and prefixes on which it will be possible to define, to what group the object concerns. In a window of the project they will be sorted alphabetically, that considerably will facilitate understanding (and вспоминание through what that time) structures of a database
• Try to adhere to monotonous system of designations (if it is not present - think up). So you considerably facilitate to yourselves (and to another who will understand your creations then) analysis of structure of base

Here an example of the system used «FreeProgramMan» (often appears on SQL.ru)

I call all objects of a DB and in a code of the program in English. If I do not know exact translation(transfer) of a word - I climb in lingvo. Plus « the Hungarian notation » - prefixes. I try to adhere to monotonous system at name inquiries, fields of tables.

For inquiries prefixes:

qr - usual inquiry doing SELECT from one/several tables
sel - filtering only unique records in connection with fields
sum - summarizing/aggregating data
pvt - cross/summary inquiry
ins - on an insert of data
upd - on updating of data

For fields of tables:

<Prefix> + <a root of the table> + <for. A word-description, sometimes two>
i <the Root - a name of the table> ID - the counter, almost always PrimaryKey
i <Root> Code - unique codes not the counter, it is frequent PrimaryKey
s <Root> Code - unique alphabetic codes
i <Root> Nomer - numbers under the order
s <Root> Name, s <Root> Description, s <Root> Comment - I think, clearly
n <Root> Count - kol something
dt <Root> Birthday, dt <Root> From, dt <Root> To, etc. – dates

But during too time, often use the mixed type of a designation. For example:

Names of objects – prefixes of objects in English, names in Russian
Names of modules, functions, procedures – in English
Names of fields of tables – prefixes in English, a name of a field in Russian

As a result it turns out:

Имена полей таблицы типа: id, idПоставщик, sПримечание и т. д.
Имена запросов: qryRptСводка_сдачи, qrySumИтог_продаж и т. д.

Though many name such approach "bad form", nevertheless, it often enough takes place. Business probably all in the same: so it is easier to search visually for object, and the English prefix is allocated among Russian letters, facilitating understanding. And even switching of an allocation of the keyboard does not stop.

Conclusion:

Finally, how to name objects of a database is a private affair of the developer, and in many respects depends THAT it writes FOR WHOM and WHAT FOR. Thus remember possible problems if use cyrillics. But, the main thing:

Use for a designation of objects of a DB the intelligent names according to the agreement on names of objects. Thus, it is extremely desirable to adhere what or systems of designations is considerably will facilitate understanding of structure of base.

to read further...

The author: Admin It is added: 08.04.2008