У Oracle длина полей 30 символов, у MSSQL и того больше. Времена dBase c 8 символьными полями канули в лету. Совремённые тулзы набора SQL-запросов имеют интеллиженс.

Cane Cat FisherДля каждой именованной сущности в проекте заведи два имени: полное и сокращенное.

Полное должно быть ясным и узнаваемым, обычно это слово без сокращения, или комбинация слов: Items, Categories, TicketСategories.

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

Например, It, Cat, TckCat

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

В коротких именах желательно следить, чтобы они отличались хотя бы двумя и более буквами, то есть чтобы не было Itm - Itn. Тогда опечатка в одном символе не приведет к смысловой ошибке, а отловится компилятором.

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


в качестве коротких имен можно, нужно использовать устоявшиеся/общеизвестные в предметной области акронимы.
Например, FPD, NPL
А просто выдумывать короткие имена - это потом еще слой перевода коротких наименований в полные наименования. 30 символов - можно вполне вложиться. А запросы будут читабельными, можно даже экспатам показывать в портфолио

stdvbNekifrovv,

СУБД какая?
если ms sql server 2005+, то можно использовать имя схемы:
items.items
items.categories
items.items_categories
tickets.tickets
tickets.categories
tickets.tickets_categories

а потом вам потребуется развернуть свою универсальную схему у другого заказчега, где СУБД не MSSQL - и алё

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

Автор молодец, если задумывается над наименованиями.

Представьте, схему вашей базы данных , тексты запросов под микроскопом пристально будут рассматривать зарубежные маститые специалисты. Если будет понятно и западным аналитикам и бизнесАм, то будете на коне. Не слушайте местных программистов
В конце концов база велозавода - отправной пример

Nekifrovv,

абсурд - это i_, t_
детский сад. Давайте, еще называйте таблицы dim_, fact_

Nekifrovv,

я не знаю каков бизнес-смысл в tickets, но абстрагируюсь.

Допустим, вы взялись за нелегкую задачищу по формализации продуктового каталога
таблицы:
product_category - категория продуктов
product_subcategory - под. категория продуктов
product - продукты
Каждая из этих таблиц имеет собственные атрибуты

Допустим, эти продукты должны M:M включаться в комплекты, тогда:
product_kit - список продуктовых комплектов (из предположения, что комплектам присваиваются какие-то коды, номера, наименования)
product_kit_product - включение (многие-ко-многим) продуктов в продуктовые комплекты;
наименование придумал в лоб, хотя может быть бизнес оперирует понятием комплектация, тогда - product_package

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


Если же в разных бизнес-сущностях у вас есть также категории, но они сводятся к виду id, name, и нет вероятности расширения их до отдельных сущностей с N-атрибутами, то создают lookUp-справочник для всех таких перечислений.

По поводу dim_, fact_ - сегодня у вас табилца как измерение, а завтра она стала и фактОвой тоже.


Еще круче, если сначала создадите, согласуете словарь бизнес-терминов, в котором будут основные термины и бизнес-синонимы,
всё это введете в Power Designer и модель данных будете проектировать в CASE-средстве с декомпозицией, PK-FK и логическими связими и т.п.
Кстати, Power Designer позвоялет контролировать длину системных наименований полей, правила именования и т.д.