    Соглашения 

    ГЛАВА 4
 
    Соблюдение стандартных соглашений о присвоении имен и структуризации 
исходного текста программы чрезвычайно облегчает разработку приложений 
клиент/сервер. Лично я считают данную тему настолько важной, 
что не могу не остановиться на ней, прежде чем приступать к обсуждению 
вопросов собственно разработки приложений. 
    В этой главе я поделюсь с вами своими соображениями по поводу соглашений, 
которых нужно придерживаться при присвоении имен элементам приложений 
клиент/сервер, создаваемых с помощью Delphi. Эта тема состоит из двух частей, 
касающихся серверной и клиентной части приложения, которые я буду 
рассматривать по отдельности. 
    Хочу обратить ваше внимание, на то, что материал данной главы содержит 
лишь мои соображения по этому вопросу. Вы можете принять их к сведению, а 
можете и проигнорировать. В конце концов, сохранение собственного стиля иногда 
больше облегчает работу, чем постоянное заимствование чужих стилей. 

    Элементы программы на языке Object Pascal 

    Мы начнем с элементов программ, создаваемых с помощью Delphi. В число 
таких элементов входят компоненты, формы, модули данных, программные модули, 
переменные, константы и т.д. Другими словами, сейчас мы будем рассматривать 
все элементы, относящиеся к программам вообще, оставив на время рассмотрение 
структуры серверов баз данных. К элементам последней относятся таблицы, 
индексы, представления, триггеры, хранимые процедуры, правила, используемые по 
умолчанию значения и т.п. Пока отложим обсуждение этих вопросов и займемся 
элементами программ общего назначения. 

    На заметку 
    Учитывая широкое разнообразие используемых сегодня операционных и сетевых 
сред, я рекомендую воздерживаться от использования имен элементов, 
использующих соглашения о длинных именах файлов Windows 95/NT. Хотя Delphi 
прекрасно справляется с такими именами, ваши приложения могут выполняться на 
компьютерах с операционными системами, не поддерживающими длинных имен. 
Учитывать это обстоятельство в отношении приложений, являющихся предметом 
рассмотрения данной книги, тем более важно, так как серверная и клиентная 
часть систем клиент/сервер по определению выполняются на разных компьютерах. 
    Я понимаю ваше нетерпение поскорее воспользоваться такой прекрасной 
возможностью, но все же прошу пока отложить использование длинных имен на 
некоторое время, пока большинство сетевых операционных систем не будет 
поддерживать длинные имена. 

    Каталоги 

    Я начинаю с каталогов, так как, учитывая тему, которой посвящена эта 
книга, имена каталогов имеют не меньшее значение, чем их содержимое. Я, 
например, храню данные приложений всех типов в каталоге жесткого диска, 
названного DATA. Это позволяет мне значительно облегчить резервное копирование 
данных: достаточно создать копию одного каталога DATA, включив режим 
резервного копирования всех подкаталогов. 

    Глава 4. Соглашения 57 

    В каталоге DATA я создаю подкаталоги для каждого приложения — каталог для 
WordPerfect, каталог для Windows, каталог для Quattro Pro for Windows и т.д. 
Это позволяет мне легко находить файлы, относящиеся к тому или иному 
приложению. Хотя мой подход и отличается от основывающейся на документах 
философии, которую исповедуют сегодня производители программного обеспечения, 
но мне он нравится. 
    В каждом подкаталоге, выделенном для отдельного приложения, я создаю 
подкаталоги для каждого из проектов, созданных с помощью этого приложения. 
Например, проект RentalMan, разработанный для части "Учебный курс" этой книги, 
находится в каталоге с:\DATA\DELPHI3\RENTMAN. В именах каталогов я не 
использую расширений и стараюсь, чтобы эти имена были как можно понятнее. Все 
файлы какого-то определенного проекта я размещаю в каталоге с соответствующим 
именем. Если проект состоит из нескольких программ, я создаю для этих программ 
каталоги, имена которых совпадают с именами содержащихся в них программ. Вы 
можете выработать свой подход, но, как я уже говорил, мой подход меня вполне устраивает. 

    На заметку 
    В Windows 95 есть стандартный каталог, который по своему назначению очень 
напоминает мой каталог DATA. Этот каталог называется My Documents (Мои 
документы). Применяя описанный выше подход, вы можете использовать не каталог 
DATA, а этот стандартный каталог Windows 95. Попутно замечу, что каталоги в 
Windows 95 называются папками (folder), которые можно создавать с помощью 
программы Explorer (проводник). 


    Проекты 

    Я всегда стараюсь присваивать проектам настолько простые имена, насколько 
это позволяют соглашения 8.3 (т.е. восемь символов — длина имени файла и три 
символа — длина его расширения). К сожалению, так как я никогда не изменяю 
стандартных расширений, присваиваемых Delphi файлам проектов, на практике я 
ограничен всего лишь восемью символами. Таким образом, имена создаваемых мною 
файлов проектов всегда совпадают с именами каталогов, в которых они находятся. 
Поэтому, даже если я на время переношу файл в другой каталог или отдаю его 
своим знакомым, я всегда могу точно установить, из какого каталога был взят 
данный проект. 

    Файлы 

    Все файлы, которые я создаю в процессе работы, имеют более или менее 
понятные и "наращиваемые" имена. Под "наращиваемостью" я подразумеваю одну или 
две цифры, используемые в качестве последних символов имени файла. Эти цифры 
позволяют мне создавать различные версии одного и того же файла без изменения 
его имени. К примеру, данная глава этой книги хранится на диске моего 
компьютера в файле с именем CSD0400. Когда я буду редактировать этот файл, я 
буду сохранять его версии с именами CSD0401, CSD0402 и т.д. Таким образом, я 
сразу могу определить, где находится самая свежая версия, не глядя на дату 
модификации. Кроме того, я облегчаю выполнение операций перемещения файлов или 
их архивации, так как могу применять при этом шаблоны. Эту схему можно 
сравнить с самой простой системой управления исходным кодом — лопатой. Кому бы 
вы не дали ее в руки, она всегда используется без дополнительных инструкций. 
    Еще одно соглашение, которого я придерживаюсь, присваивая имена файлам, 
касается префикса, идентифицирующего проект, к которому относится данный файл. 
Использование префикса обеспечивает подобие имен всех файлов проекта и 
облегчает управление файлами. Например, имена всех файлов системы Rental 
Maintenance Management System, которую мы создадим во второй части этой книги, 
начинаются с буквы R. 
    Обычно используемые мной префиксы имеют дину от трех до шести символов, 
описывающих общее назначение файла. Если назначение какого-то конкретного 
файла не отличается от общего назначения всех остальных файлов проекта, я 
использую все шесть символов. В тех же случаях, когда файл имеет некоторое 
специфическое назначение, я использую три символа для описания его общего 
назначения и три символа для описания конкретного назначения этого файла. 
Например, в системе Rental Maintenance Management System имеется файл, 
назначение которого состоит в создании диалогового окна редактирования таблицы 
CALLS. Этот файл называется RCALEDTO — как нетрудно догадаться, название 
происходит от Rental maintenance management system, Call Edit dialog box. 
Можно использовать и другие комбинации символов, главное — обеспечить 
системность в присвоении имен. Например, некоторые мои знакомые программисты 
разбивают упоминавшиеся выше шесть символов на глагол и существительное. 
Глагол описывает действие, а существительное — объект, над которым выполняется 
это действие. 

    58 Часть I. Основы 


    Удобопроизносимость имен 

    Еще одним аспектом присвоения имен файлам, о котором нельзя не упомянуть, 
является их удобопроизносимость. Некоторые так увлекаются "кодированием" имен 
файлов, что доводят это до абсурда. Старайтесь не заходить в этом направлении 
слишком далеко. Имена файлов, в которых каждая буква что-нибудь означает, 
трудно запомнить и, как правило, практически невозможно произнести. Работая 
над проектом, вам часто придется разговаривать о тех или иных файлах со своими 
коллегами, и неправильный выбор имени файла может помешать работе. Например, 
если мне понадобиться обсудить файл RCALEDTO, я могу сказать: "Джо, помнишь 
файл R-Call-Edit, над которым мы работали полгода тому назад?" Скорее всего, 
Джо сразу же поймет, о чем я говорю, благодаря правильно выбранному имени файла. 

    Программные модули 

    Как и имена файлов, имена программных модулей могут быть длинными, хотя и 
не до такой степени — длина последних ограничена "всего" 63 символами. Как уже 
упоминалось, я все же рекомендую воздержаться от имен, длина которых превышает 
восемь символов. Имена, которые вы присваиваете программным модулям, Delphi 
автоматически использует в качестве имен файлов этих модулей по правилами 
операционной системы. Поэтому создание модуля с именем длиной более восьми 
символов по умолчанию приведет в Windows к сохранению исходного текста этого 
модуля в файле, длина имени которого также будет превышать восемь символов. 

    Компоненты 

    Поскольку между именами компонентов и именами файлов, в которых они 
содержатся, нет прямой связи, вы можете делать их такой длины, какая 
необходима. Старайтесь, чтобы имена компонентов позволяли приблизить текст 
программы к естественному языку и, самое главное, были понятны для вас. Однако 
не забывайте, что чрезмерное увлечение длинными именами может привести к тому, 
что вам придется постоянно барабанить по клавиатуре, особенно если такое имя 
было присвоено часто используемому компоненту. Еще один прием, которым я 
рекомендую пользоваться для повышения наглядности текста программы, — 
применение букв в разных регистрах. Поскольку в именах компонентов пробелы не 
допускаются, разграничение отдельных слов с помощью прописных букв существенно 
облегчает восприятие имен. Наконец, как вы увидите в следующем разделе, я 
рекомендую предварять все имена типов (включая объявления компонентов, которые 
являются типами классов) прописной буквой T. Это соглашение используется в 
библиотеке визуальных компонентов (VCL — Visual Component Library), 
разработанной компанией Borland для Delphi. Соблюдение данного соглашения 
облегчает поиск объявлений типов в исходном тексте программ. Например, 
компонент, представленный в листинге 3.5 предыдущей главы, называется 
ТАrrауТаblе. Префикс Т говорит о том, что это тип класса Object Pascal, a 
ArrayTable описывает назначение этого компонента. 
    Присваивая значения свойству Name встроенных компонентов Delphi, я всегда 
использую двух- или четырехсимвольный мнемонический префикс, облегчающий 
определение типа компонента. Например, компоненты Memo я предваряю префиксом 
mе, компоненты Edit — префиксом ed и т.д. Остальная часть идентификатора 
должна представлять собой более или менее вразумительное описание объекта, например: 
    edCustomerName или meComments. В табл. 4.1 приведены рекомендации по 
обозначению типов компонентов при присвоении имен объектам. Обратите внимание, 
что в этот список я включил также классы Form и DataModule, так как объекты 
этих классов часто используются в программах. 

    Таблица 4.1. Компоненты Delphi и соответствующие им префиксы 
    
    Компонент	Префикс	Компонент	Префикс 

    Animate		an		ListBox		lb 
    AutoObject 	ao		ListView		lv 
    BatchMove	bm		MainMenu		mm 
    BDEProvider	bp		MaskEdit		md 
    BDEResolver	br		MediaPlayer		mp 
    Bevel		be		Memo			me 
    BitBtn		bb		MemoryDataSet	ms 


    Глава 4. Соглашения 59 


    Продолжение табл. 4.1 

    Компоненг		Префикс	Компонент		Префикс 

    Button				bt	Notebook			nb 
    Calendar			ca	OleContainer		ol 
    Chart				ch	OpenDialog			od_
    ChartFX				ex	OpenPictureDialog		op_ 
    CheckBox			ck	Outline			ou 
    CheckListBox			clb	PageControi			pc 
    ClientDataSet			cd	PageProducer		pp 
    ClientSocket			cs	PaintBox			pb 
    Colorbar			co	Panel				pa 
    ColorDialog			co_	PopupMenu			pu 
    ColorGrid			cg	PrintDialog			pr_
    ComboBox			cb	PrinterSetupDialog	ps_
    CoolBar				co	ProgressBar			pr 
    Database			db	QRBand			qba 
    DataModule			dm	QRChart			qch 
    DataSetTableProducer	dp	QRChildBand			qcb 
    DataSource			ds	QRCompositeReport		qcr 
    DateTimePicker		dt	QRDBCalc			qdc 
    DBChart				dch	QRDBImage			qdi 
    DBCheckBox			dck	QRDBText			qdt 
    DBComboBox			deb	QRDetailLink		qdl 
    DBCtrlGrid			dcg	QREditor			qed 
    DBEdit				ded	QRExpr			qex 
    DBGrid				dgr	QRGroup			qgr 
    DBImage				dim	QRImage			qim 
    DBListBox			dib	QRLabel			qla 
    DBLookupCombo			dico	QRMemo			qme 
    DBLookupComboBox		dicb	QRPreview			qpr 
    DBLookupList			dlli	QRRichText			qrt 
    DBLookupListBox		dllb	QRShape			qsh 
    DBMemo				dme	QRSubDetail			qsd 
    DBNavigator			dna	QRSysData			qrs 
    DBRadioGroup			drg	Query				qu 
    DBText				dte	QueryTableProducer	ЧР 
    DdeClientConv			cc	QuickRep			qr 
    DdeClientItem			ci	RadioButton			rb 
    DdeServerConv			sc	RadioGroup			rg 
    DdeServer  			si	RemoteServer		rs 

    
    60 Часть I. Основы 


    Окончание табл. 4,1 

    Компонент			Префикс	Компонент	Префикс 

    DecisionCube			cde	ReplaceDialog	re 
    DecisionGraph			cgp	Report		rp 
    DecisionGrid			cgr	RichEdit		re 
    DecisionPivot			cpi	SaveDialog		sa 
    DecisionQuery			cqu	SavePictureDialog	sp 
    Decisionsource		cds	ScrollBar		sa 
    DirectoryListBox		dl	ScroliBox		sx 
    DirectoryOutline		do	ServerSocket	ss 
    DrawGrid			dr	Session		se 
    DriveComboBox			dc	SpeedButton		sb 
    Edit				ed	SpinButton		su 
    FIBook				fl	SpinEdit		sd 
    FileListBox			fl	Splitter		si 
    FilterComboBox		fc	StatusBar		st 
    FindDialog			fi	StoredProc		sp 
    FontDialog			fo	StringGrid		sq 
    Form				fm	TabbedNotebook	tn 
    FTP				ftp	TabControl		tc 
    Gauge				ga	Table			ta 
    Graph				gr	TabSet		ts 
    GraphicsServer		gs	Thread		th 
    GroupBox			gb	Timer			ti 
    Header				he	Toolbar		to 
    HeaderControl			he	TrackBar		tb 
    HotKey				hk	TreeView		tv 
    HTMLDataSetTableProducer	ht	UpdateSQL		us 
    HTMLPageProducer		hp	UpDown		ud 
    HTMLQueryTableProducer	hq	VSSpell		vs 
    HTTPDispatcher		hd	VtChart		vc 
    IBEventAlerter		le	WebBrowser		wb 
    Image				im	WebDispatcher	wd 
    ImageList			il	WebSession		ws 
    Label				la 
    
    Префиксы для имен объектов диалоговых окон приводятся в табл. 4.1 в виде 
двух букв, за которыми следует символ подчеркивания (_). Это делается для 
выделения их среди других объектов. Обратите внимание также на то, что почти 
все префиксы, используемые при обозначении имен объектов для работы с базами 
данных, соответствуют префиксам аналогичных объектов стандартных элементов 
управления с добавлениям перед ними буквы d. Например, для имен объектов 
компонентов Edit используется префикс ed, а для имен объектов компонентов 
DBEdit — префикс ded. 

    Глава 4. Соглашения 61 

    Совет 
    Некоторые CASE-средства позволяют определять соглашения по присвоению имен 
объектам в генерируемых ими программах. Например, S-Designor (последняя версия 
называется PowerDesignor) дает пользователю возможность создать шаблоны имен, 
определяющие имена генерируемых объектов. Если вы пользуетесь такими 
средствами, можете настроить их в соответствии с описываемыми в данной главе 
соглашениями. 

    Типы 

    Присвоение имен типам лучше всего осуществлять в соответствии с теми же 
правилами, которые использовались для присвоения имен компонентам. Предваряйте 
все имена объявляемых типов заглавной буквой T, после которой следует 
собственно имя программного элемента, по возможности, описывающее его 
назначение. Выбирайте длину имени в разумных пределах, чтобы не выполнять 
лишней работы при вводе текста программы с клавиатуры. Для того чтобы повысить 
наглядность текста, используйте прописные и строчные буквы. Все вышесказанное 
распространяется и на объявление классов, которые являются в Object Pascal 
специальным типом данных. Вот пример объявления простого типа данных: 

    TRecordMouse = (rmAll, rmNone, rmClickAndDrags); 


    Константы 

    Для имен констант я рекомендую использовать только прописные буквы, как 
это обычно делается для констант языка С, объявляемых с помощью директивы 
#define. Такая форма записи поможет вам отличить константы, которые не должны 
изменяться, от переменных, которые, наоборот, могут и должны изменяться в ходе 
выполнения программы. Ниже приведено объявление константы из исходного текста 
компонента LiveQuery, о котором пойдет речь в главе 27, "Разработка 
компонентов баз данных": 

    DEFAULTCREATEVIEWSQL = 'CREATE VIEW %s AS '; 


    Переменные 

    Для имен переменных я использую комбинации слов, отделяемых друг от друга 
заглавными буквами. Имена переменных должны быть описательными и, в то же 
время, достаточно короткими. Ниже приведен пример правильного присвоения имен 
переменным, взятый из того же исходного текста компонента 

    TLiveQuery: 
    TemporaryDB: TDatabase; 
    WorkSQL: TStrings; 

    Иногда я использую еще один подход, заключающийся в указании перед именем 
переменной односимвольного префикса, указывающего на область видимости этой 
переменной: 1 — для локальных переменных, g — для глобальных и с — для 
переменных класса. Иногда это оказывается полезным при определении области 
видимости переменной, так как помогает избавиться от необходимости тщательного 
изучения исходного текста всех функций, процедур и объявлений классов приложения. 

    Процедуры и функции 

    Соглашения по присвоению имен процедурам и функциям практически ничем не 
отличаются от аналогичных соглашений для переменных. Единственное различие 
состоит в том, чтобы с помощью имен можно было распознать, является ли данный 
идентификатор именем переменной или же именем функции, не имеющей параметров. 
Так например, посмотрев на следующий фрагмент программы, нельзя однозначно 
сказать, какой именно элемент представлен идентификатором SalesTax: 

    х := SalesTax; 

    Чтобы избежать подобных ситуаций, добавляйте префикс Get перед именами 
функций, не имеющих параметров. Вообще добавление такого префикса к именам 
всех функций — неплохая идея, хотя в некоторых ситуациях данный префикс будет 
избыточным. Например, среди функций стандартной библиотеки Delphi есть функция 
FileOpen — в ее имени префикс Get ни к чему. 

    62 Часть I. Основы 

    Соглашения, которых придерживались разработчики компании Borland при 
написании исходного текста VCL, определяют использование префикса Set для всех 
процедур, присваивающих значения свойствам, и Get — для всех функций, 
возвращающих такие значения. Эти же соглашения можно распространить и на те 
процедуры и функции, которые не работают со свойствами компонентов. 

    Оформление программ на языке Object Pascal 

    Еще одной областью, нуждающейся в стандартизации, является оформление 
исходного текста программ. Исследовав этот вопрос, вы, наверняка, обнаружите, 
что в данной области каждый программист придерживается собственного стиля, 
который хоть в чем-то, но отличается от других стилей и подходов. Но, хотя 
никто не может вам дать рекомендаций, которые были бы неоспоримы, можно 
сказать одно — лучше все же иметь хоть какой-то стиль, чем вообще никакого. 
Если при написании программы выдерживаются те или иные правила оформления ее 
исходного текста, то такую программу легче читать и сопровождать. В данном 
разделе я поделюсь своими соображениями о правилах оформления операторов 
ifelse, блоков begin-end и комментариев. Однако здесь, как и в присвоении 
имен, важнее не следование тому или иному стилю, включая и мой, а 
последовательность в использовании хоть какого-то стиля. 

    Операторы if-else 

    Одним из приемов оформления, к которому я прибегаю в операторах if-else, 
является использование скобок, даже если в них нет необходимости. Этому есть 
два объяснения. Во-первых, на мой, взгляд, использование скобок облегчает 
восприятие и понимание условных выражений. Во-вторых, что более важно, 
добавляя второе условное выражение, мне не нужно изменять первое. В отличие от 
языка С, в Pascal одно условное выражение можно не заключать в скобки, поэтому 
следующий оператор является вполне допустимым: 

    if х = 1 then у := z; 

    Однако два или более условных выражения, используемых в качестве условия 
одного оператора if, требуют заключения их в скобки: 

    if (х = 1) or (x*2 = 4) then у := z; 

    Если в вашей программе оператор if имел вид, приведенный в первом примере, 
то при добавлении в него еще одного условного выражения вам придется заключить 
в круглые скобки не только это выражение, но и первое. В случае простых 
условных выражений особых проблем нет, но когда первое выражение довольно 
сложно и имеет внутри несколько пар круглых скобок, то добавление лишних 
скобок при расширении условия может послужить дополнительным источником 
ошибок. Так как использование необязательных скобок не влечет за собой никаких 
накладных расходов, то лучше использовать их сразу, чтобы потом не вносить 
изменения в уже отлаженную часть выражения. 

    БЛОКИ begin-end 

    Еще одним соглашением, которого я придерживаюсь не только в операторах 
if-else, но и в других конструкциях, допускающих использование операторных 
блоков, заключается в том, чтобы помещать ключевое слово begin в той строке, 
где находится оператор самой конструкции. Для операторов if это означает, что 
я располагаю ключевое слово begin в той же строке, что и оператор if. Так как 
язык Pascal поддерживает свободный стиль оформления исходного текста, вы 
можете помещать слово begin где угодно — в одной строке с оператором if, в 
следующей строке или даже через пять строк. В любом случае это влияет только 
на внешний вид программы, а код, генерируемый компилятором, будет одним и тем 
же. Вот пример программы, оформленной в соответствии с соглашениями, которых 
придерживаюсь я: 

    if (х = 1) then begin 
       у := z; 
       closefile; 
    end; 

    Многие программисты используют, например, такой стиль: 

    if (х = 1) then 
     begin 
      у := z; 


    Глава 4. Соглашения 63 


      closefile; 
    end; 

    Такой подход мне не нравится из-за того, что практически впустую 
расходуется пространство экрана. Учитывая небольшой размер окна редактирования 
исходного текста в Delphi, вы также почувствуете, что данный стиль могут 
позволить себе только счастливые обладатели дисплеев с экранами огромного 
размера. Далее, использование отступа также не всегда можно трактовать 
однозначно. Нужно ли использовать такой же отступ, как и для оператора if, 
ведь пара begin-end — не оператор, а всего лишь разделитель? Может операторный 
блок нужно сместить к концу оператора if, ведь такой блок как бы продолжает 
оператор if? А как насчет программного кода, находящегося внутри операторного 
блока? Какой отступ использовать — относительно оператора if или относительно 
ключевого слова begin? В соответствии с соглашениями, которых придерживаюсь я, 
ключевое слово begin находится в той же строке, что и оператор if, поэтому все 
вопросы относительно отступов отпадают сами собой. Более того, в этом случае 
ключевое слово end служит ограничителем оператора if, что соответствует логике 
программы. Наконец, программный код внутри операторного блока выравнивается 
относительно оператора if, что показывает его зависимость от данного 
оператора, а не от ключевого слова begin. 
    Некоторые программисты записывают ключевые слова begin и end операторного 
блока в верхнем регистре. Я не пользуюсь этим, так как, на мой взгляд, когда 
исходный код испещрен прописными буквами, то кажется, будто операторы вот-вот 
выпрыгнут с экрана и начнут лаять на вас. Если, к тому же, вспомнить, что 
ключевые слова begin и end — всего-навсего ограничители, которые при 
компиляции не порождают никакого объектного кода, то становится понятным, что 
использование для них прописных букв является слишком большой привилегией. 
Верхний регистр букв нужно применять для тех элементов, которые действительно 
заслуживают вашего внимания (например, для констант), а не для пары ключевых 
слов, которыми усеян исходный код любого приложения, вне зависимости от его размера. 

    Комментарии 

    Язык Object Pascal поддерживает комментарии трех типов — (*...*), {...} и 
//. Я использую символы {...} для создания обычных комментариев, т.е. таких, 
которые объясняют назначение программного файла или его фрагмента. Когда я 
использую временные комментарии, которых в отлаженной программе не должно 
быть, я прибегаю к символам (*...*). Это облегчает поиск тех фрагментов, 
которые я временно отключил с помощью комментария. Если же мне нужно на время 
отключить только одну строку исходного текста, я использую символы //. 
    Если у вас возникнет необходимость в использовании вложенных комментариев 
или в применении внутри ограниченного комментарием текста символов, 
совпадающих с символами самого комментария, вам придется отступить от принятых 
правил. Например, поясняя синтаксис функции SendKeys, мне понадобилось в 
тексте комментария использовать символы фигурных скобок, так они являлись 
частью синтаксиса этой функции. Поэтому в данном случае мне пришлось 
отказаться от использования в качестве символов комментария фигурных скобок, 
поскольку компилятор не мог правильно определить начало и конец комментария, и 
применить символы (*...*). 

    Элементы серверов баз данных 

    За годы, которые я занимаюсь программированием, мне удалось выработать 
соглашения по наименованию элементов серверов SQL, что, к счастью, помогло мне 
сохранить психическое здоровье. Больше базы данных очень похожи на большие 
программы — чем взвешеннее вы подходите к присвоению имен, тем проще 
становится ваша жизнь. Если имена присваиваются объектам согласно системе, они 
становятся вашим путеводителем по базе данных. 
    Соблюдение таких соглашений не только поможет вам в системном 
сопровождении базы данных, но и облегчит разработку и восприятие запросов. 
Язык SQL возник как результат идеи создания языка запросов, который имел бы, с 
одной стороны, достаточно четко определенную структуру, а с другой — был бы 
близок к естественным языкам и прост в использовании. Если вы присваиваете 
объектам базы данных вразумительные и систематизированные имена, то ваши 
запросы будут понятными и прозрачными. 
    Как и в случае элементов программ на языке Object Pascal, все предложения, 
рассмотренные в данном разделе, выражают лишь точку зрения одного человека. Вы 
можете использовать другие соглашения. Идея заключается в том, чтобы иметь 
такие соглашения и быть последовательным в их применении. 

    64 Часть I. Основы 

    На заметку 
    В материале этого раздела я признаюсь в своем пристрастии к присвоению 
имен объектам сервера, в которых используются как прописные, так и строчные 
буквы. Такой же подход я применяю при настройке серверов, которые могут 
различать регистр букв. Конечно, если используемый вами сервер нечувствителен 
к регистру (например, InterBase или, в определенных конфигурациях, SQL Server) 
использование разных регистров лишено всякого смысла. Хотя с помощью данного 
подхода можно улучшить внешний вид процедур SQL, иногда он не работает на 
таких серверах. Используемый вами сервер базы данных может не сохранять или не 
воспринимать имена, записанные с помощью букв разных регистров. Например, при 
использовании прописных и строчных букв в имени столбца таблицы многие 
серверы, сохраняя таблицы на диске, преобразуют все буквы в прописные. В таких 
случаях я рекомендую использовать символы подчеркивания, чтобы, с одной 
стороны, облегчить восприятие имен, а с другой — обойти зависимость от 
настройки сервера. 


    Серверы 

    О том, что стандартизованный подход к назначению имен серверам баз данных 
важен не меньше, чем назначение имен их объектам, известно достаточно мало. 
Если вам приходится управлять множеством серверов баз данных, то выработка 
принципа присвоения им имен может уберечь вас от разного рода неприятностей. 
    Присваивая имена серверам баз данных, я использую восьмисимвольные 
идентификаторы, записываемые в верхнем регистре. Первые три буквы обозначают 
тип сервера: SQL для Sybase или Microsoft SQL Server, ORA для Oracle Server, 
SQA для SQL Anywhere и т.д. Три следующих символа указывают, предназначен ли 
сервер для разработки программного обеспечения, его тестирования или 
производственных целей. В качестве таких обозначений можно использовать, 
например DEV, TST и PRO. Два последних символа представляют собой номер версии 
и могут изменятся в диапазоне от 1 до 99 (нуль зарезервирован с целью, о 
которой я скажу чуть позже). Это позволяет мне настраивать по несколько версий 
одного и того же сервера. 
    Лучше всего эти соглашения проиллюстрировать примером. Допустим, вы 
работаете с сервером Sybase SQL Server, который является вашим единственным 
сервером, используемым для разработки программ. Согласно моим соглашениям, имя 
этого сервера будет SQLDEV01. Версия же этого сервера, используемого для 
производственных целей, будет называться SQLPR001. 
    Итак, имена серверов — это первое, с чего вы должны начать при выработке 
системного подхода к присвоению имен элементам базы данных. 

    Совет 
    Нулевой номер версии в имени сервера я резервирую для специальных целей. 
Например, я могу создать временный сервер Oracle для разработки программ и 
присвоить ему имя ORADEVOO. Или мне может понадобиться установить на своем 
портативном компьютере сервер Sybase SQLDEVOO, который, строго говоря, 
является сервером, хотя у него в таком случае будет только один пользователь. 
Так или иначе, резервирование нулевого номера версии помогает мне выполнять 
нестандартные задачи, поэтому я рекомендую вам прибегнуть к такому подходу. 

    На заметку 
    Если вы не являетесь администратором базы данных, то причина для включения 
номера версии в имя сервера может показаться вам слегка надуманной. В конце 
концов, действительно, ну зачем вам несколько экземпляров одного сервера? 
Опытные администраторы знают ответ на этот вопрос. Если вы управляете 
кластером серверов любой сложности, то время от времени у вас будет возникать 
необходимость в нескольких серверах для разработки программ, их тестирования 
или выполнения производственных задач. Кроме того, может возникнуть 
необходимость распределить серверы по приложениям либо по отделам, которые их 
используют, или же создать несколько серверов, чтобы повысить 
производительность приложений. Наконец, вы можете прийти к выводу, что 
безопаснее развернуть серверы на нескольких машинах, чем "затыкать дыры" в 
единственном вышедшем из строя сервере, используемом всеми службами предприятия. 

    Глава 4. Соглашения 
    3 Delphi 3 и системы клиент/сервер 65 

    Какой СУБД вы бы ни управляли, у вас время от времени возникает 
необходимость в обновлении операционной системы или программного обеспечения 
сервера базы данных. При этом вы, конечно же, будете предпринимать все 
возможное, чтобы не нарушить целостность работающей системы. Например, вы вряд 
ли станете обновлять производственный сервер, не проверив сначала новые 
программы. Общепринятым является подход, заключающийся в создании сервера на 
другой машине, установка на нем необходимого программного обеспечения с 
последующим переносом информации со старого сервера на новый. Такой подход 
позволяет избежать опасности разрушения работающего сервера при установке на 
него непроверенных программ. Часто администраторы баз данных сначала 
устанавливают обновленные версии на тестовых серверах или серверах, 
используемых для разработки программного обеспечения, а лишь затем, 
убедившись, что все работает как следует, устанавливают их на производственных 
серверах. Допустим, например, что администратор базы данных Oracle хочет 
обновить программное обеспечение производственного сервера ORAPR001 и 
установить на него новую версию СУБД Oracle. Для этого можно воспользоваться 
следующей последовательностью действий. 
    1. Установить обновленную версию на сервер ORADEV01, выделенный для 
разработки программ. 
    2. Скопировать данные производственного сервера на обновленный сервер. 
    3. Убедившись, что обновленная система работает без сбоев, переименовать 
сервер в ORAPR002, так как сервер ORAPR001 уже существует, и переключить все 
приложения, используемые в производственном процессе, на сервер ORAPR002. В 
системах семейства UNIX это можно сделать с помощью средств автоматического 
присвоения имен, такого как DNS. 
    4. После настройки нового производственного сервера переименовать прежний 
производственный сервер ORAPR001 в ORADEV01, чтобы снова получить сервер для 
разработки программ. 
    5. Установить обновленное программное обеспечение на новый сервер ORADEV01 
(бывший ORAPROOI). 
    Данный подход к обновлению системы, не требующий настройки нового сервера 
"с нуля", является самым безопасным из всех мне известных. А использование 
соглашений о присвоении имен, как показано в приведенном выше примере, делает 
его гораздо проще и понятнее. (Не стоит даже говорить о том, что создание 
надежных резервных копий на каждой стадии является основным методом 
обеспечения безопасности при обновлении любой системы.) 

    Базы данных 

    Базы данных, как уже было сказано, — это набор таблиц, а не отдельные 
таблицы. Присваивая имена базам данных, я всегда использую только строчные 
буквы. Регистр имеет значение, так как некоторые серверы баз данных по 
умолчанию различают регистр букв. В начале имени я использую префикс, 
состоящий из последовательности от одного до трех символов, предназначенный 
для идентификации системы, к которой принадлежит база данных. Если база данных 
используется несколькими приложениями, я присваиваю ей имя более общего 
характера. После префикса я использую одну—четыре буквы для того, чтобы 
отличать основные базы данных от транзакционных. Основные базы данных — это 
базы, состоящие из практически неизменяемых таблиц, откуда выбираются имена и 
другая информация описательного характера. Транзакциончыми я называю базы 
данных, которые изменяются гораздо чаще, например ежедневно. Транзакционные 
базы данных, как правило, заполняются пользователями или устройствами. Иногда 
основные и транзакционные базы данных отделены друг от друга, иногда — 
образуют единую базу данных. Для того чтобы в полной мере воспользоваться 
преимуществом их разделения, присвойте таким базам соответствующие имена. 

    На заметку 
    Некоторые СУБД (например, InterBase), не имеют средств поддержки 
взаимодействия между базами данных. Иначе говоря, используя такие СУБД, нельзя 
создать основную таблицу в одной базе данных, а транзакционную — в другой. 
Поэтому, приступая к разработке структуры базы данных, выясните, поддерживает 
ли ваша СУБД возможность обращения к внешним базам данных. Если СУБД не 
обладает такой возможностью, то разделение базы данных на основную и 
транзакционную может оказаться невозможным. 

    Иногда в имени базы данных я также использую номер версии, состоящий из 
одной-двух цифр. Это позволяет работать сразу с несколькими вариантами одной 
базы данных, хотя на практике такая необходимость возникает достаточно редко. 
Прибегая к таким соглашениям, я могу присвоить основной базе 

    66 Часть I. Основы 

данных бухгалтерской системы имя actmast0. Здесь act означает 
принадлежность базы данных к бухгалтерской системе (accounting system), mast 
говорит о том, что база данных является основной (master), a 0 указывает на 
то, что это первая версия базы данных. 
    Обратите внимание, что к длине имен баз данных я по-прежнему применяю 
восьмисимвольное ограничение. Это продиктовано тем, что процедуры SQL 
какой-либо конкретной СУБД, применявшейся для создания базы данных, могут не 
поддерживать длинных имен файлов, которые обычно присваиваются в соответствии 
с именами баз данных. Кроме того, имя базы данных может соответствовать имени 
сценария SQL, который ее создавал. Хотя теоретически такой сценарий может 
хранится и не на сервере, а на жестком диске рабочей станции, операционная 
система которой может поддерживать длинные имена, однако лучше всего сразу 
присваивать короткие имена. Тогда впоследствии вам не придется сталкиваться с 
различными неприятностями при перемещении файлов и помнить о необходимости их 
переименования. 

    Файлы данных 

    Большинство СУБД масштаба предприятия отделяют описания баз данных от их 
физического содержимого. Эта операция выполняется специальными подсистемами, 
работающими на промежуточном уровне между базами данных и драйверами дисков, 
на которых эти базы хранятся. В СУБД SQL Server, например, такие подсистемы 
называются логическими устройствами (logical device), а в Oracle — файлами 
данных (data file). В таких СУБД файлы данных работают непосредственно с 
дисковыми устройствами, а базы данных — только с файлами данных. Такой подход 
позволяет распределять базы данных по нескольким устройствам и даже по 
нескольким серверам без каких-либо дополнительных затрат. 
    Обычно я присваиваю файлам данных (логическим устройствам) имена, подобные 
тем, которые я использую для соответствующих баз данных. Такой подход 
продиктован тем обстоятельством, что я обычно сегментирую файлы данных таким 
образом, чтобы каждый из них отвечал за хранение только одной базы данных. В 
каждом имени файла данных я применяю трехбуквенное обозначение функций данного 
файла. Затем я указываю число, определяющее номер данного файла в группе 
подобных файлов. В завершение я добавляю к имени файла расширение DAT. 
Помните, что к файлам данных можно обратиться извне сервера, используя лишь 
средства операционной системы. Поэтому, применяя одинаковые расширения, я тем 
самым облегчаю поиск этих файлов и выполнение над ними групповых операций. 
    Лучше всего продемонстрировать применение этих соглашений на примере. 
Допустим, у меня имеется файл данных, в котором я сохраняю информацию базы 
данных с именем medical. Первый файл данных я назову meddatOO.dat. Точно так 
же, имя первого файла журнала (log file) для данного устройства будет иметь 
вид medlogOO.dat. Первые три символа означают базу данных, которую обслуживает 
данное устройство, следующие три — показывают назначение данного файла, а 
номер идентифицирует данный файл в наборе таких же файлов. 

    На заметку 
    СУБД SQL Server позволяет определить как физическое, так и логическое имя 
файла логического устройства. Все вышесказанное распространяется только на 
физические имена. В качестве логического имени можно использовать, например, 
физическое имя без расширения.     

    В практике нередки случаи, когда разработчики базы данных, руководствуясь 
соображениями производительности, точно определяют место размещения отдельных 
таблиц и индексов. В СУБД SQL Server для этого используются сегменты 
(segment), а в Oracle — табличные области (tablespace). При настройке 
логического устройства, которое будет использовано для размещения только 
одного сегмента или одной табличной области, я присваиваю ему соответствующее 
имя. Например, файл данных, связанный с табличной областью с именем 
billingdata, может быть назван bildatOO.dat, а логическое устройство, 
связанное с сегментом generalledgerindexes, — glidatOO.dat. Основная идея 
состоит в том, чтобы по имени файла, доступному из операционной системы, можно 
было определить, с каким логическим устройством он связан. Такой подход 
облегчает восстановление базы данных и ее резервирование. 

    Таблицы 

    Присваивая имена таблицам, я всегда использую только прописные буквы. 
Основной довод в пользу такого подхода заключается в том, что таблицы являются 
ключевым элементом базы данных. Кроме того, имена таблиц, набранные в верхнем 
регистре, облегчают работу с операторами SQL. Хотя многие совре-

    Глава 4. Соглашения 67 

менные СУБД допускают использование в именах объектов букв любого 
регистра, применение только прописных букв в именах таблиц позволяет облегчить 
восприятие исходных текстов сценариев SQL и хранимых процедур. 
    В качестве имен таблиц я стараюсь использовать одно-два коротких слова 
(как и прежде, до восьми символов), определяющих назначение таблицы. В данном 
случае номера версий не используются — все подчинено главной идее: сделать имя 
настолько простым, насколько это возможно. Данный подход позволяет существенно 
упростить и облегчить разработку запросов SQL. Чем сложнее имя таблицы, тем 
труднее его прочесть и запомнить. Поэтому следует отдавать предпочтение 
коротким и, по возможности, состоящим из одного слова именам. Примерами таких 
имен могут быть INVOICES, ORDERS, CUSTOMER и т.п. 
    Как и прежде, напоминаю о восьмисимвольном ограничении длины имени. 
Соблюдение данного правила позволит присвоить файлам сценариев SQL, создающих 
таблицы, имена, совпадающие с именами таблиц, вне зависимости от используемой 
операционной системы. 

    Совет 
    Присваивая таблицам имена, которые будут понятны пользователям базы 
данных, в один прекрасный день вы можете столкнуться с приятным сюрпризом, 
когда пользователи начнут проявлять интерес к самостоятельной разработке 
запросов SQL. Как показывает практика, в случае применения не слишком 
"заумных" соглашений по присвоению имен, пользователи, поработав с базой 
данных, начинают самостоятельно пробовать свои силы в разработке запросов с 
помощью тех или иных визуальных средств. 


    Индексы 

    Многие диалекты SQL не позволяют прямого доступа к индексным таблицам в 
запросах, поэтому вопрос о необходимости выработки соглашений по присвоению 
имен индексам отпадает сам собой. Я применяю подход, состоящий в присвоении 
индексам имени, совпадающего с именем таблицы, по которой они построены, с 
добавлением порядкового номера индекса по данной таблице. Например, первый 
индекс, построенный по таблице CUSTOMER, будет иметь имя CUSTOMER01, второй — 
CUSTOMER02 и т.д. Номера, используемые в именах индексов, совпадают с 
номерами, присваиваемыми индексам в такой СУБД, как Sybase SQL Server, что 
позволяет облегчить разработку высокопроизводительных запросов, работающих с 
конкретными индексами. 

    Представления 

    Представления (view) нужно называть так же, как и таблицы. В SQL 
представления и таблицы обрабатываются практически одинаково, поэтому 
использование одинаковых соглашений при создании их имен вполне оправдано. 
Некоторые предпочитают добавлять к именам представлений префиксы или суффиксы 
вида V или VW, но на практике особой нужды в них не возникает. 

    Хранимые процедуры и функции 

    Присваивая имена хранимым процедурам (stored procedure) и функциям, я 
всегда использую только строчные буквы. Это позволяет легко отличать их от 
имен таблиц и других объектов в запросах SQL. Однако, как я уже отмечал, 
современные серверы различают верхний и нижний регистры, поэтому вы можете 
использовать соглашения, которые вам больше по душе. В любом случае нужно 
сохранять общую идею — применяя различные соглашения для различных объектов, 
вы тем самым облегчаете работу с запросами. 
    Некоторые программисты добавляют символы зр в начале или конце имен 
хранимых процедур, однако в этом нет острой необходимости. Вряд ли у вас 
возникнет потребность в использовании хранимой процедуры в таком же контексте, 
как и при использовании другого объекта, например таблицы. Проще говоря, вы 
вряд ли когда-нибудь станете применять операторы SQL, подобные SELECT * FROM, 
к хранимым процедурам и уж наверняка никогда не станете запускать на 
выполнение таблицы с помощью команды EXECUTE. Если, все-таки, вы привыкли 
что-то искать в текстах хранимых процедур, как если бы они были таблицами 
(такая возможность поддерживается, например, InterBase), то можете 
воспользоваться префиксом или суффиксом sp. В остальных случаях можно вполне 
обойтись и без них. 

    68 Часть I. Основы 


    Внимание 
    Создание хранимой процедуры с именем, начинающемся с символов sp_, в СУБД 
Sybase SQL Server и Microsoft SQL Server приведет к тому, что такая процедура 
будет помещена в базу данных master. Размещение пользовательских объектов в 
этой базе данных является признаком плохого стиля администрирования, которого 
нужно избегать. Поэтому, если вы хотите обозначить хранимые процедуры с 
помощью символов зр, лучше использовать суффикс _sр. 

    Возвращаясь к именам, хочу отметить, что я применяю к именам хранимых 
процедур те же правила, о которых я говорил при описании соглашений о 
присвоении имен программным модулям Object Pascal. Первый символ имени я 
использую для идентификации приложения, которому принадлежит данная процедура. 
За ним следует от трех до шести символов, которые описывают общее и конкретное 
назначение данной процедуры. Завершают имя одна или две цифры, представляющие 
номер версии. 
    Например, для процедуры, выводящий содержимое таблицы CALLS из базы данных 
Rental Maintenance Management System, я присвоил бы имя RCALLST0. Первая буква 
R идентифицирует систему, к которой принадлежит процедура, CAL указывает на 
таблицу CALLS, с которой работает данная процедура, a LST говорит о том, что 
данная процедура выводит (list) содержимое данной таблицы. Цифра 0 в конце 
имени означает номер версии данной процедуры. 

    На заметку 
    В СУБД Sybase и Огасlе используется одно логическое имя для нескольких 
хранимых процедур. В Oracle вы "перегружаете" (overload) назначенное имя, 
указывая реальную процедуру, которую хотите в дальнейшем применять под этим 
именем. В Sybase после имени процедуры ставится точка и номер версии, 
указывающий на конкретную процедуру данного вида. Я рекомендую не прибегать к 
этому. Выгоды в данном случае весьма незначительны, а путаница, которая подчас 
создается, может привести к достаточно серьезным последствиям. 


    Пакеты 

    Так как пакеты (package) предназначены для инкапсуляции хранимых процедур 
и функций, в присвоении им имен я придерживаюсь соответствующих соглашений. 
Имена всех объектов я записываю в нижнем регистре, а с помощью первого символа 
имени идентифицирую приложение, к которому относится данный пакет. Затем я 
применяю от трех до шести символов, описывающих общее и конкретное назначение 
данного пакета. В конце имени я указываю букву р вместо номера версии, как в 
именах хранимых процедур и функций. 

    Правила 

    Если используемый вами сервер поддерживает правила (rule), присваивайте им 
понятные описательные имена с применением букв разных регистров. Нужно 
выработать какую-то систему, чтобы имена правил были ограничивающими 
(restrictive) или разрешающими (permissive). Разрешающее имя правила указывает 
на набор данных, которые разрешены этим правилом. И наоборот, ограничивающее 
имя правила говорит о том, какие наборы данных ограничивает это правило. Лично 
я предпочитаю разрешающие имена. Например, если правило ограничивает ввод нуля 
в поле, я назвал бы его NonZero, а если оно предписывает ввод в поле Sex 
только букв М или F, я использовал бы имя MaleFemale. В запросах SQL редко 
применяются обращения к правилам, поэтому имена последних не имеют особого 
значения. Кроме того, поскольку правила относятся к объектам баз данных, для 
которых в SQL не существует специальной команды CREATE, создающей 
индивидуальный сценарий, то в данном случае нет необходимости в соблюдении 
восьмисимвольного ограничения длины имени. 

    Используемые по умолчанию значения 

    Если сервер, с которым вы работаете, поддерживает объекты, представляющие 
используемые по умолчанию значения столбцов (default), присваивая имена этим 
объектам, используйте имя соответствующего поля (если они используются только 
для одного поля) и собственно значение (регистр букв может быть 

    Глава 4. Соглашения 69 

любым). Например, если у поля Sex имеется используемое по умолчанию 
значение F, то такому объекту нужно присвоить имя SexFemale. Поскольку 
используемые по умолчанию значения редко применяются в запросах SQL, их имена 
не имеют особого значения. Более того, поскольку для объектов данного типа не 
предусмотрено специальной команды создания сценария CREATE, то на них не 
распространяется ограничение длины имени в восемь символов. 

    Домены 

    Так как домены (domain), т.е. определяемые пользователем типы данных, 
очень похожи на типы данных языка Object Pascal, присваивая имена доменам, я 
применяю соответствующие соглашения. В качестве первого символа домена я 
использую заглавную букву T, за которой следует имя столбца, определяемого 
доменом. Например, домен, определяющий столбец CustomerNo, будет назван 
TCustomerNo. Такое имя позволяет, с одной стороны, показать, что данный домен 
определяет столбец CustomerNo, а с другой — быстро найти его от в операторе 
CREATE TABLE среди встроенных типов данных. Домены относятся к объектам баз 
данных, для которых в SQL не существует специальной команды CREATE, создающей 
индивидуальный сценарий, поэтому нет необходимости в соблюдении 
восьмисимвольного ограничения длины имени домена. 

    Ограничения и исключительные ситуации 

    Присваивая имена объектам этого типа, я основываюсь на сообщениях, которые 
идентифицируют проблему, возникшую в связи с нарушением ограничения или 
приведшую к генерации исключительной ситуации. Такой подход имеет целью дать 
пользователю представление о проблеме уже по имени одного объекта, поскольку 
некоторые средства разработки некорректно обрабатывают сообщения сервера 
(особенно сообщения, связанные с нарушением ограничений). Такие средства часто 
возвращают имя объекта в верхнем регистре, независимо от того, в каком виде 
оно хранится в базе данных. Поэтому для имен этих объектов я использую верхний 
регистр и символы подчеркивания. Например, для ограничения на внешний ключ, 
обеспечивающего ввод правильного номера клиента, я применил бы имя 
INVALID_CUSTOMER_NO. В таком случае, при нарушении ограничения и использовании 
средства разработки, которое выводит только имя объекта, пользователь все 
равно будет знать, в чем причина проблемы. Такой же подход я применяю к 
присвоению имен объектам исключительных ситуаций, чтобы в случае отсутствия в 
средстве разработки поддержки вывода сообщений, пользователь мог понять, в чем 
причина возникновения исключительной ситуации. Исключительные ситуации и 
ограничения — еще два вида объектов, для которых в языке SQL не предусмотрено 
специальной команды создания сценария CREATE, поэтому на них также не 
распространяется ограничение длины имени в восемь символов. 

    Генераторы и последовательности 

    Как и в случае доменов, я присваиваю имена генераторам (generator) и 
последовательностям (sequence), в соответствии с именами обслуживаемых ими 
столбцов. К имени столбца я добавляю символы GEN (для имен генераторов) или 
SEQ (для имен последовательностей). Например, генератору, обслуживающему 
столбец CustomerNo, я присвою имя CustomerNoGEN, а последовательности, 
предназначенной для заполнения столбца OrderNo — имя OrderNoSEQ. Генераторы и 
последовательности также относятся к объектам баз данных, для которых в SQL не 
существует специальной команды CREATE, создающей индивидуальный сценарий, 
поэтому их имена можно не ограничивать восемью символами. 

    Курсоры 

    Обычно я присваиваю имена курсорам в соответствии с именами таблиц, с 
которыми они работают. Кроме того, в именах курсоров я указываю, позволяет ли 
данный курсор выполнять обновление. Для этого к имени курсора я добавляю слово 
UPDATE или, соответственно, слово SELECT. Например, курсор таблицы TENANT, 
позволяющий обновление и удаление, можно назвать TENANT UPDATE, а курсор 
таблицы PROPERTY, который не позволяет обновления, — PROPERTY SELECT. 

    70 Часть I. Основы 


    Триггеры 

    В именах триггеров я рекомендую использовать имена связанных с ними 
таблиц, за которыми следует команда SQL, приводящая триггер в действие. Так 
как триггеры могут запускаться командами INSERT, UPDATE или DELETE, в любой 
комбинации, то в именах триггеров нужно перечислять все эти команды. Например, 
триггер, срабатывающий при вставке или обновлении строки таблицы TENANT, можно 
назвать TENANTlnsertUpdate, а триггер, срабатывающий при удалении записи из 
таблицы WORDERS, — WORDERSDelete. 
    Если ваш сервер позволяет указать, срабатывает ли триггер до или после 
возникновения некоторого события, добавьте в имя такого триггера слова Before 
или After, соответственно. Можно, например, присвоить триггеру, срабатывающему 
перед выполнением над таблицей PROPERTY оператора SQL DELETE, ИМЯ 
PROPERTYBeforeDelete ИЛИ PROPERTY_BEFORE_DELETE. 
    Некоторые СУБД различают триггеры строк (row trigger) и операторные 
триггеры (statement trigger). В таких случаях я добавляю в конце имени триггера 
букву R или S, соответственно, например: 
    PROPERTY_BEFORE_DELETE_S. Увидев такое имя, я сразу же понимаю, для чего 
предназначен этот триггер и с какой таблицей он связан. 
    Триггеры относятся к объектам баз данных, для которых в SQL не существует 
специальной команды CREATE, создающей индивидуальный сценарий, поэтому их 
имена можно не ограничивать восемью символами. 

    Столбцы 

    Столбцы (column) — самый популярный объект в запросах SQL, поэтому к 
присвоению им имен нужно подходить особенно тщательно. Имена столбцов нужно 
выбирать таким образом, чтобы они были близки к естественному языку, а при их 
записи нужно использовать буквы разных регистров. Если ваш сервер не различает 
прописных и строчных букв, то используйте символы подчеркивания между 
отдельными словами имен столбцов. Выбирая имена столбцов, не бойтесь 
показаться слишком многословными — те, кто спустя несколько лет будет 
сопровождать ваши программы, скажут вам спасибо. Имена должны быть такими, 
чтобы можно было однозначно определить назначение каждого конкретного столбца 
в таблице базы данных. Столбцы, которые в разных таблицах представляют одну и 
ту же сущность, например идентификационный код клиента, должны иметь 
одинаковые имена во всех таблицах базы данных, например CustomerNo. Если вы 
применяете сокращения для таких элементов имени, как Number или Address, то 
будьте последовательны при использовании этих элементов во всех таблицах. 
Например, не присваивайте полю, в котором хранится код клиента, имя 
CustomerNum, если раньше присвоили полю, предназначенному для хранения номера 
заказа, имя OrderNo. В качестве примеров правильно выбранных имен столбцов 
можно привести OrderNo, ShippingAddress, SampleWeight, AverageWellDepth и т.д. 

    Совет 
    По-настоящему можно прочувствовать пользу присвоения продуманных имен 
столбцам при использовании средств визуального проектирования, которые 
автоматически генерируют метки создаваемых полей по имени столбца. Например, 
при перетаскивании поля из окна редактора полей Delphi на форму автоматически 
создается метка этого поля. В качестве заголовка этой метки используется имя 
столбца из таблицы базы данных. Если при выборе имени вы руководствовались 
хорошо продуманными соглашениями, то часто заголовок метки можно будет 
оставить без изменений. Таким образом, взвешенный и системный подход к 
присвоению имен не только помогает разбираться в структуре базы данных, но и 
облегчает разработку приложений. 


    Резюме 

    Разработка соглашений по присвоению имен программным элементам и объектам 
баз данных — довольно утомительная процедура, но результат стоит потраченных 
усилий. Это облегчит понимание программ не только вашим коллегам, но и вам, 
когда придется вносить изменения в исходный текст, к которому вы прикасались в 
последний раз полгода тому назад. Это относится и к стилю оформления текста 
программ. Даже если ваш стиль отличается от стиля других программистов, 
требуется совсем немного времени, чтобы разобраться в том, как структурирована 
программа, если ее автор уделял вопросу структу-

    Глава 4. Соглашения 71 

ризации должное внимание. Тщательно поработав над вышеупомянутыми 
вопросами, вы в последствии никогда не будете ломать голову над тем, что 
обозначает тот или иной идентификатор, или где найти на диске тот или иной 
объект. Лучше потратить какое-то время на разработку соглашений, чтобы потом 
не терять его на разгадывание "кроссвордов" из исходного кода, а 
сконцентрироваться на решении задач, действительно заслуживающих внимания. 
    В данной главе не были упомянуты все возможные элементы баз данных и 
программ. Я не привел, например, никаких рекомендаций по присвоению имен 
кластерам, используемым в СУБД Oracle. Если для вас эти элементы имеют большое 
значение — вы можете выработать собственные подходы. Главная мысль, которую я 
пытался в этой главе донести до моих читателей, заключается в том, чтобы 
использовать хоть какиенибудь соглашения, даже если они частично или полностью 
не совпадают с моими рекомендациями. 
    В табл. 4.2 приведены все соглашения о присвоении имен элементам сервера 
баз данных, которые я упоминал в этой главе. 
    Таблица 4.2. Соглашения о присвоении имен элементам сервера баз данных 

  Объект     Соглашения              Регистр Максималь- Пример 
                                             мая длина 
                                             имени 
Сервер   	                         Верхний    8       SQLPR001
Первые три символа означают тип   
сервера (SQL Server, Oracle и т.д.),
следующие три символа — его назначение (производство, разработка программ, 
тестирование), последние два символа — номер версии сервера 

База данных                         Нижний     8       medmast 
Первые три символа означают приложение, которое работает с этой 
базой данных, все остальные — тип базы данных (основная, транзакци-онная и 
т.п.) 

Файл данных                         Нижний     8 и      medlogOO.dat 
(логическое                                    расширение 
устройство) 
Первые три символа означают соответствующую базу данных, cледующие три 
символа — тип файла (DAT для файла данных, LOG — для файла журнала транзакций 
и т.п.), два последних — номер версии. К имени файла добавляется расширение 
DAT 

Таблица                              Верхний   8 PATIENT 
Однословное имя, отражающее назначение таблицы 

Индекс                              Верхний Нет PATIENTOI
Имя соответствующей таблицы с  добавлением номера индекса 

Представление                       Верхний 8 PATIENT или PATIENT_V 
Однословное имя, отражающее назначение представления таблицы. Для того 
чтобы различать имена представлений и таблиц, можно добавить в конце имени 
представления символы v 

Хранимая процедура                 Нижний   8  mpatlstO  
Первый символ означает приложение, следующие три символа — общее назначение 
процедуры или функции, еще три символа — конкретное назначение, последний 
символ — номер версии 

    72 Часть I. Основы 


    Окончание табл. 4.2 

    Объект	Соглашения	             Регистр	Максимальная  Пример 
                                                длина имени	 

    Пакет	                          Нижний	8	mpatupdp 
Первый символ означает приложение, следующие три — общее назначение 
пакета, следующие три — конкретное назначение пакета. Последний символ 
предназначен для указания на то, что данное имя принадлежит пакету	

    Правило	                          Любой	Нет	NonZero 
Комбинация слов, показывающая, какой тип данных ограничивается или 
разрешается этим правилом. Я предпочитаю использовать разрешающие имена	
    Используемое по умолчанию значение Любой	Нет	StateTexas 
Объединение имени соответствующего столбца и используемого по умолчанию значения

    Домен	                          Любой	Нет	TCustomerNo 
Буква Т, за которой следует имя соответствующего столбца	

    Ограничение,                      Верхний	Нет	INVALIDCUSTOMERNO 
    исключительная ситуация	
Состоящий из нескольких слов идентификатор, указывающий на причину возникновения 
исключительной ситуации	

    Генератор, последовательность	  Любой	Нет	CustomerNoSEQ 
Имя соответствующего столбца с добавлением суффикса SEQ (для последовательностей) или 
GEN (для генераторов)	
    Курсор	                         Верхний	Нет	TENANT SELECT 
Имя соответствующей таблицы, за которым следует слово UPDATE или SELECT	
    Триггер	                         Любой	Нет	TENANT InsertUpdate 
Имя соответствующей таблицы, за которым следует перечень операций, 
приводящих к срабатыванию триггера	
    Столбец	                         Любой	Нет	HomePhoneNo 
Идентификатор, точно описывающий назначение данных, содержащихся в столбце	

    
    На заметку
    Как я уже упоминал ранее в этой главе, некоторые СУБД не поддерживают 
идентификаторы, использующие разные регистры букв. В таких случаях применяйте 
прописные буквы, отделяя слова друг от друга с помощью символов подчеркивания. 
Например, в СУБД InterBase идентификатор HomePhoneNo можно записать в виде 
HOME_PHONE_NO. Хотя такие идентификаторы выглядят не очень эстетично, но зато 
позволяют практически без изменений соблюсти соглашения о присвоении имен. 

    Глава 4. Соглашения 73 


    В этой главе я остановился на соглашениях, используемых в программировании 
на языке Object Pascal и присвоении имен различным элементам. Вот краткий 
перечень рассмотренных вопросов. 
    Q Структура каталогов, в которых вы размещаете проекты, должна быть хорошо 
продуманной. В таком случае можно не заботится о том, что вы помещаете в тот 
или иной каталог, — достаточно знать, куда вы помещаете объект, чтобы позднее 
легко разобраться в его назначении. 
    Q Имена проектов надо выбирать таким образом, чтобы можно было без труда 
определить, к какой системе относится тот или иной выполняемый файл. Лучше 
всего присваивать файлам проектов и каталогам, в которых они размещаются, 
одинаковые имена. 
    Q Воздержитесь, во всяком случае на некоторое время, от использования 
длинных имен файлов Windows 95/NT. Желательно, чтобы имена файлов 
соответствовали стандарту 8.3, независимо от применяемой операционной системы. 
Имена файлов должны быть удобопроизносимы и понятны. 
    Q Хотя программные модули могут иметь длинные имена, лучше всего называть 
их в соответствии с именами их файлов. Это означает, что длина имени 
программного модуля не должна превышать восьми символов. Если имя файла 
программного модуля было выбрано правильно, то длинное имя для самого модуля 
не понадобится. 
    Q Имена классов компонентов так же, как и имена типов данных, нужно 
начинать с символа T. Имя должно как можно лучше описывать назначение 
компонента; при необходимости в нем нужно использовать прописные и строчные буквы. 
    О Константы должны иметь идентификаторы, записанные в верхнем регистре. 
    Q Переменные нужно называть как можно понятнее и, при необходимости, 
использовать в их именах прописные и строчные буквы. 
    Q Лично я предпочитаю заключать в круглые скобки все условные выражения, 
используемые в программе, даже если в этом нет необходимости. Такой подход 
позволяет облегчить последующее добавление других условных выражений. 
    Q Я также предпочитаю помещать ключевое слово begin, начинающее 
операторный блок, на одной строке с оператором, к которому оно относится. 
    Q В Object Pascal применяются три типа символов комментария. Символы // 
используются для создания однострочных, а символы (*...*) и {...} — 
многострочных комментариев. Лучше всего использовать один из типов символов 
комментариев-скобок для собственно комментариев в исходном тексте программ, а 
другой — для временного отключения тех или иных операторов. 

    Что дальше. 

    В следующей главе вы ознакомитесь с основами SQL. Я постарался изложить 
минимальный набор необходимых сведений о SQL так, чтобы материал был понятен 
даже непосвященным. Поэтому, если вы не знаете, что такое язык SQL и как 
использовать его возможности в приложениях, создаваемых с помощью Delphi, — 
добро пожаловать в главу 5, "SQL для простых смертных". 

    74 Часть I. Основы 

