Соглашения об именах баз данных, таблиц и столбцов? [закрытый]

поздний ответ здесь, но вкратце:

1. мой предпочтения во множественном числе
2. Да
3. таблицы: * обычно * нет префиксов лучше всего. колонки: нет.
4. обе таблицы и столбцы: PascalCase.

разработка:

(1) что вы должны сделать. есть очень мало вещей, которые вы должны сделать определенным образом, каждый раз, но есть несколько.

• имя первичные ключи использование формата" [singularOfTableName]ID". То есть, является ли ваше имя таблицы клиент или клиенты первичный ключ должен быть CustomerID.
• далее внешние ключи должны называться последовательно в разных таблицах. Должно быть законно избивать того, кто этого не делает. Я бы предположил, что, хотя определенные ограничения внешнего ключа are часто важно, согласованное имя внешнего ключа всегда важно
• вы должны иметь базу данных внутренние конвенций. Хотя в последующих разделах вы увидите, что я очень гибкая, внутри имя базы данных должно быть очень согласованным . Называется ли ваша таблица для клиентов клиенты или клиент менее важно, чем то, что вы делаете это одинаково во всей той же базе данных. И вы можете перевернуть монету, чтобы определить, как использовать подчеркивания, но тогда вы должны продолжать использовать их таким же образом. Если вы этого не сделаете, вы плохой человек, у которого должна быть низкая самооценка.

(2) что вы, вероятно, должны сделать.

• поля, представляющие один и тот же тип данных в разных таблицах должны назовите то же самое. У вас нет Zip на одном столе и ZipCode на другом.
• В отдельные слова в именах таблиц или столбцов используйте PascalCasing. Использование camelCasing не было бы внутренне проблематичным, но это не конвенция, и это выглядело бы смешно. Я обращусь к подчеркиваниям через минуту. (Вы не можете использовать ALLCAPS, как в старые времена. OBNOXIOUSTABLE.Досадно, что 20 лет назад все было в порядке, но не сейчас.)
• не искусственно сокращать или сокращать слова. Лучше, чтобы имя было длинным и ясным, чем коротким и запутанным. Ультра-короткие имена пережиток более темных и жестоких времен. Cus_AddRef. Что это? Ссылка На Адресата? Клиент Дополнительный Возврат? Пользовательский Адрес Реферала?

(3) что вы должны рассмотреть.

• Я действительно думаю, что у вас должны быть имена множественного числа для таблиц; некоторые думают единственного числа. Читать доводы других. Однако имена столбцов должны быть единственными. Даже если вы используете имена таблиц множественного числа, таблицы, которые представляют комбинации других таблиц могут быть в единственном числе. Например, если у вас есть акции и предметы таблица, таблица, представляющая элемент, являющийся частью акции, может быть Promotions_Items, но это также может быть promotion_items, я думаю (отражая отношение "один ко многим").
• используйте подчеркивания последовательно и для определенной цели. Просто общие имена таблиц должны быть достаточно ясными с PascalCasing; вам не нужно подчеркивает отдельные слова. Сохранить подчеркивания (a) для указания ассоциативной таблицы или (b) для префикса, к которому я обращусь в следующем пуле.
• префикс не является ни хорошим, ни плохим. Это обычно не лучше. В ваших первых БД или двух я бы не предложил использовать префиксы для общей тематической группировки таблиц. Таблицы в конечном итоге не подходят для ваших категорий легко, и это действительно может сделать это сильнее найти столы. С опытом, вы можете планировать и применяйте схему префиксов, которая приносит больше пользы, чем вреда. Однажды я работал в БД, где таблицы данных начинались с tbl, таблицами конфигурации с ctbl по, С vew труды по sp, и udf fn и несколько других; он был тщательно, последовательно применен, поэтому все получилось хорошо. Единственный раз, когда вам нужны префиксы, - это когда у вас есть действительно отдельные решения, которые по какой-то причине находятся в одной БД; префиксы могут быть очень полезно при группировании таблиц. Префикс также подходит для особых ситуаций, например для временных таблиц, которые вы хотите выделять.
• очень редко (если вообще) вы хотите для префикса столбцов.

хорошо, так как мы взвешиваем с мнением:

Я считаю, что имена таблиц должны быть в единственном числе. Таблицы-это коллекция (таблица) сущностей. Каждая строка представляет один объект, а таблица представляет коллекцию. Поэтому я бы назвал таблицу личностных сущностей людьми (или людьми, что угодно, что вам нравится).

для тех, кто хочет видеть сингулярные "имена сущностей" в запросах, я бы использовал псевдонимы таблиц для:

SELECT person.Name
FROM People person

немного похоже на LINQ "от человека в людях выбирают человека.Имя".

Что касается 2, 3 и 4, я согласен с @Lars.

Я работаю в команде поддержки базы данных с тремя СУБД, и наши рассмотренные варианты:

1. любой стандарт именования лучше, чем стандартные.
2. нет" одного истинного " стандарта, у всех нас есть свои предпочтения
3. если стандарт уже на месте, используйте его. Не создавайте еще один стандарт или мутите существующие стандарты.

мы используем в единственном числе имена таблиц. Таблицы, как правило, имеют префикс с именем системы (или ее акроним.) Это полезно, если системный комплекс, как вы можете изменить префикс для группировки таблиц вместе логически (т. е. reg_customer, reg_booking и regadmin_limits).

для полей мы ожидаем, что имена полей будут включать префикс / acryonm таблицы ( т. е. cust_address1), и мы также предпочитаем использовать стандартный набор суффиксов (_id для PK, _cd для "кода", _nm для "имени", _nb для "числа", _dt для "даты").

имя поля ключа Foriegn должно быть то же, что и поле первичного ключа.

то есть

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

при разработке нового проекта я бы рекомендовал вам записать все предпочтительные имена сущностей, префиксы и акронимы и предоставить этот документ своим разработчикам. Затем, когда они решают создать новую таблицу, они могут ссылаться на документ, а не "угадывать", как следует называть таблицу и поля.

1. нет. Таблица должна быть названа в честь сущности, которую она представляет. Человек, а не люди-это то, как вы бы назвали того, кого представляет одна из записей.
2. опять то же самое. Столбец FirstName действительно не должен называться FirstNames. Все зависит от того, что вы хотите представить в виде столбца.
3. нет.
4. да. Дело это для ясности. Если вам нужно иметь столбцы, такие как" FirstName", корпус облегчит чтение.

ОК. Вот мои 0.02$

Я также выступаю за соглашение об именах стилей ISO/IEC 11179, отмечая, что они являются руководящими принципами, а не предписывающими.

посмотреть имя элемента данных в Википедии:

"таблицы являются коллекциями сущностей и следуют рекомендациям по именованию коллекций. В идеале используется коллективное имя: например., Персонал. Множественное число также правильно: сотрудники. Неправильные имена включают: сотрудник, tblEmployee и EmployeeTable."

Как всегда, есть исключения из правил, например, таблица, которая всегда имеет ровно одну строку, может быть лучше с единственным именем, например, таблица конфигурации. И последовательность имеет первостепенное значение: проверьте, есть ли у вас в магазине соглашение, и если да, следуйте ему; Если вам это не нравится, сделайте бизнес-кейс, чтобы он изменился, а не был одиноким рейнджером.

наше мнение:

1. должны быть имена таблиц во множественном числе?
   Никогда. Аргументы в пользу того, что это коллекция, имеют смысл, но вы никогда не знаете, что будет содержать таблица (0,1 или много элементов). Правила множественного числа делают именование излишне сложным. 1 Дом, 2 дома, мышь против мыши, человек против людей, и мы даже не смотрели на любые другие языки.

   Update person set property = 'value' действует на каждого человека в таблице.
   Select * from person where person.name = 'Greg' возвращает коллекцию строк из рядов персон.

2. должны ли имена столбцов быть единственными?
   Обычно, да, за исключением случаев, когда вы нарушаете правила нормализации.

3. должен ли я префикс таблиц или столбцов?
   В основном предпочтение платформы. Мы предпочитаем префиксные столбцы с именем таблицы. Мы не префиксные таблицы, но мы делаем префиксные представления (v_) и stored_procedures (sp_ или f_ (функция)). Это помогает людям, которые хотят попытаться обновить v_person.возраст, который на самом деле вычисляемое поле в представлении (которое все равно не может быть обновлено).

   это также отличный способ избежать столкновения ключевых слов (доставка.от перерывов, но delivery_from не делает).

   это делает код более подробным, но часто помогает в удобочитаемости.

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... очень четкий и явный. Это может выйти из-под контроля, хотя:

   customer.customer_customer_type_id

   показывает отношение между клиентом и таблица customer_type, указывает первичный ключ в таблице customer_type (customer_type_id), и если вы когда-либо видели "customer_customer_type_id" во время отладки запроса, вы мгновенно знаете, откуда он (таблица customer).

   или где у вас есть отношение M-M между customer_type и customer_category (только определенные типы доступны для определенных категорий)

   customer_category_customer_type_id

   ... немного (!) на длинном сторона.

4. должен ли я использовать любой случай в именовании элементов? Да-нижний регистр:), с подчеркиванием. Они очень читабельны и кросс-платформенны. Вместе с 3 выше это также имеет смысл.

   большинство из них, хотя предпочтения. - Пока вы последовательны, это должно быть предсказуемо для всех, кто должен это прочитать.

взгляните на ISO 11179-5: принципы именования и идентификации Вы можете получить его здесь: http://metadata-standards.org/11179/#11179-5

Я писал о ней здесь: ISO-11179 Соглашения об именах

Я все время слышу аргумент, что множественность или нет таблицы-это вопрос личного вкуса, и нет лучшей практики. Я не верю, что это правда, особенно как программист в отличие от DBA. Насколько мне известно, нет никаких законных причин для плюрализации имени таблицы, кроме "это просто имеет смысл для меня, потому что это коллекция объектов", в то время как есть законные выгоды в коде, имеющие сингулярные имена таблиц. Для пример:

1. Это позволяет избежать ошибок и ошибок, вызванных множественными двусмысленностями. Программисты точно не известны своим орфографическим опытом, и плюрализация некоторых слов сбивает с толку. Например, слово множественного числа заканчивается на " es "или просто "s"? Это люди или люди? Когда вы работаете над проектом с большими командами, это может стать проблемой. Например, экземпляр, в котором член команды использует неправильный метод для множественного числа создаваемой таблицы. К тому времени, как я взаимодействую с эта таблица используется во всем коде, к которому у меня нет доступа или потребуется много времени для исправления. В результате я должен помнить, что пишу таблицу неправильно каждый раз, когда я ее использую. Со мной произошло нечто очень похожее. Чем проще вы можете сделать это для каждого члена команды, чтобы последовательно и легко использовать точные, правильные имена таблиц без ошибок или искать имена таблиц все время, тем лучше. Сингулярная версия намного проще обрабатывать в команде окружающая среда.

2. Если вы используете сингулярную версию имени таблицы и префикс первичного ключа с именем таблицы, теперь у вас есть преимущество легко определить имя таблицы из первичного ключа или наоборот только с помощью кода. Можно дать переменной с именем таблицы в ней, сцепить "код" до конца, и теперь у вас есть первичный ключ таблицы через код, без необходимости делать дополнительный запрос. Или вы можете отрезать "Id" от конца первичного ключа до определите имя таблицы с помощью кода. Если вы используете " id " без имени таблицы для первичного ключа, вы не можете с помощью кода определить имя таблицы из первичного ключа. Кроме того, большинство людей, которые плюрализируют имена таблиц и префиксные столбцы PK с именем таблицы, используют сингулярную версию имени таблицы в PK (например, статусы и statusId), что делает невозможным это вообще.

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

4. Если вы сделаете имя таблицы сингулярным, это сделает вашу схему именования последовательной, организованной и простой в обслуживании в каждом месте. Вы знаете, что в каждом экземпляре вашего кода, будь то имя столбца, имя класса или имя таблицы, это то же самое имя. Это позволяет выполнять глобальный поиск, чтобы видеть везде, где используются данные. Когда вы плюрализуете имя таблицы, будут случаи, когда вы будете использовать сингулярную версию этого имени таблицы (класс, в который он превращается, в первичном ключе). Просто имеет смысл не иметь некоторых случаев, когда ваши данные называются множественным числом, а некоторые экземпляры единственными.

подводя итог, если вы во множественном ваши имена таблиц вы теряете всякие преимущества в сделать ваш код умнее и проще в обращении. Могут быть даже случаи, когда вам нужно иметь таблицы/массивы поиска для преобразования имен таблиц в объектные или локальные кодовые имена, которых вы могли бы избежать. Сингулярные имена таблиц, хотя, возможно, сначала чувствуют себя немного странно, предлагают значительные преимущества перед множественными именами, и я считаю, что это лучшая практика.

Я знаю, что это поздно для игры, и на вопрос уже ответили очень хорошо, но я хочу предложить свое мнение о #3 относительно префикса имен столбцов.

все столбцы должны быть названы с префиксом, уникальным для таблицы, в которой они определены.

например. Учитывая таблицы "клиент" и "адрес", перейдем к префиксам "cust" и "addr" соответственно. "клиент" будет иметь "cust_id", "cust_name" и т. д. в этом. "адрес" бы "addr_id", "addr_cust_id" (FK back to customer), "addr_street" и др. в этом.

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

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

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

другое, относительно небольшое преимущество в том, что вам нужно использовать только псевдонимы таблиц, когда вы делаете self join:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

мое мнение по этим вопросам:

1) Нет, имена таблиц должны быть в единственном числе.

в то время как это, кажется, имеет смысл для простого выбора (select * from Orders) это имеет меньше смысла для эквивалента OO (Orders x = new Orders).

таблица в БД-это действительно набор этого объекта, это имеет больше смысла, как только вы используете set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

эта последняя строка, фактическая логика соединения, выглядит запутанной с именами таблиц множественного числа.

Я не уверен всегда используя псевдоним (как предлагает Мэтт), это очищает.

2) они должны быть единственными, поскольку они имеют только 1 свойство

3) Никогда, если имя столбца неоднозначно (как указано выше, где у них обоих есть столбец с именем [Key]), имя таблицы (или ее псевдоним) может различать их достаточно хорошо. Вы хотите, чтобы запросы были быстрыми для ввода и простыми-префиксы добавляют ненужную сложность.

4) Все, что вы хотите, я бы предложил CapitalCase

Я не думаю, что есть один набор абсолютных рекомендаций по любому из них.

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

на мой взгляд:

1. имена таблиц должны быть в единственном числе.
2. имена столбцов должны быть в единственном числе.
3. нет.
4. либо CamelCase (мой предпочтительный), либо underscore_separated для имен таблиц и столбцов.

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

1. определенно держите имена таблиц в единственном числе, человек не люди
   1. тут же
   2. нет. Я видел некоторые ужасные префиксы, доходящие до того, что заявляли, что имеют дело с таблицей (tbl_) или процедурой хранилища пользователей (usp_). Затем следует имя базы данных... Не делай этого!
   3. да. Я склонен PascalCase все мои имена таблиц

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

поскольку на это нет правильного ответа, вы должны занять некоторое время (но не слишком много) и выбрать свои собственные соглашения и - здесь важная часть-придерживайтесь его.

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

на всякий случай, вот мои ответы:

1. да. Таблица-это группа записи, учителя или актеры, поэтому... множественный.
2. да.
3. я ими не пользуюсь.
4. база данных, которую я использую чаще - Firebird-хранит все в верхнем регистре, поэтому она не имеет значения. Во всяком случае, когда я программирую, я пишу имена так, чтобы их было легче читать, например releaseYear.

Соглашения об именах позволяют команде разработчиков проектировать discovereability и ремонтопригодность в центре проекта.

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

вот мои ответы:

1. да, имена таблиц должны быть множественными, когда они относятся к набору сделки, ценные бумаги или контрагенты например.
2. да.
3. да. Таблицы SQL имеют префикс tb_, представления-префикс vw_, хранимые процедуры-префикс usp_, а триггеры-префикс tg_, за которым следует имя базы данных.
4. имя столбца должно быть в нижнем регистре, разделенном подчеркивать.

именование трудно, но в каждой организации есть кто-то, кто может назвать вещи, и в каждой команде программного обеспечения должен быть кто-то, кто несет ответственность за стандарты именования и гарантирует, что вопросы именования, такие как sec_id, sec_value и security_id получить решение рано, прежде чем они запекаются в проекте.

Итак, каковы основные принципы хорошего соглашения об именах и стандартов: -

• используйте язык вашего клиента и ваш домен решения
• описанием
• будьте последовательны
• неопределенность, отражение и рефакторинг
• Не используйте сокращения, если они понятны всем
• Не используйте зарезервированные ключевые слова SQL как имена столбцов

вот ссылка, которая предлагает несколько вариантов. Я искал простую спецификацию, которой мог следовать, а не полагаться на частично определенную.

http://justinsomnia.org/writings/naming_conventions.html

имена таблиц всегда должны быть единственными, потому что они представляют собой набор объектов. Как вы говорите, стадо обозначает группу овец, или стадо обозначает группу птиц. Не нужно множественного числа. Когда имя таблицы состоит из двух имен и соглашение об именовании во множественном числе, становится трудно узнать, должно ли имя множественного числа быть первым словом или вторым словом или обоими. Это логический объект.экземпляр, а не объекты.пример. Или TableName.колонка, не TableNames.колонка(ы). Microsoft SQL не является случаем чувствительный, легче читать имена таблиц, если используются прописные буквы, для разделения имен таблиц или столбцов, когда они состоят из двух или более имен.

Имя Таблицы: Она должна быть особой, поскольку она является единой сущностью, представляющей реальный объект, а не объекты, которые singlular.

Столбец Имя: он должен быть сингулярным только тогда, когда он передает, что он будет иметь атомное значение и подтвердит теорию нормализации. Если, Однако, есть n количество свойств одного и того же типа, то они должны быть суффиксами с 1, 2, ..., н и т. д.

префиксные таблицы / столбцы: это огромный тема, обсудим позже.

корпус: это должен быть корпус верблюда

мой друг, Патрик Керхер, Я прошу вас не писать ничего, что может быть оскорбительным для кого-то, как вы написали: "•далее, внешние ключи должны быть названы последовательно в разных таблицах. Должно быть законно избивать того, кто этого не делает.". Я никогда не делал этой ошибки, мой друг Патрик, но я пишу вообще. Что если они вместе планируют избить тебя за это? :)

очень поздно на вечеринку, но я все еще хотел добавить свои два цента о префиксах столбцов

существует два основных аргумента для использования стандарта именования столбцов table_column (или tableColumn), оба основаны на том, что само имя столбца будет уникальным во всей вашей базе данных:

1) Вам не нужно указывать имена таблиц и/или псевдонимы столбцов в ваших запросах все время

2) Вы можете легко найти весь код для столбца имя

Я думаю, что оба аргумента ошибочны. Решение обеих проблем без использования префиксов простое. Вот мое предложение:

всегда используйте имя таблицы в SQL. Е. Г., всегда используйте таблицы.столбец вместо столбца.

Это, очевидно, решает 2), так как теперь вы можете просто искать таблицу.столбец вместо table_column.

но я слышу, как вы кричите, как это решает 1)? Это было как раз для того, чтобы избежать этого. Да, это так, но ... решение было ужасно ошибочным. Почему? Ну, решение префикса сводится к:
Чтобы избежать необходимости указывать таблицу.столбец когда есть двусмысленность, вы называете все свои столбцы table_column!
Но это означает, что отныне вам всегда придется писать имя столбца каждый раз, когда вы указываете столбец. Но если вам все равно нужно это сделать, в чем преимущество над всегда явно написанной таблицей.колонка? Точно, нет никакой пользы, это точно такое же количество символов тип.

edit: да, я знаю, что именование столбцов с префиксом обеспечивает правильное использование, тогда как мой подход зависит от программистов

основные соглашения об именах баз данных (и стиль) (нажмите здесь для более подробного описания)

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

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

имена таблиц в единственном числе. Допустим, вы моделировали отношения между кем-то и его адресом. Например, если Вы читаете datamodel вы бы предпочли каждый человек может жить по 0,1 или много адресов.' или каждый человек может жить по 0,1 или много адресов.' Я думаю, что его легче плюрализировать адрес, а не перефразировать людей как человека. Плюс коллективные существительные довольно часто dissimlar в единственном варианте.

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

это условности, которым меня учили, но вы должны адаптироваться к тому, что вы используете для разработки шланга.

1. множественном числе. Это коллекция сущностей.
2. да. Атрибут представляет собой представление сингулярного свойства сущности.
3. да, имя префиксной таблицы позволяет легко отслеживать имена всех индексов ограничений и псевдонимов таблиц.
4. случай Pascal для имен таблицы и столбца, префикс + все крышки для индексов и ограничения.