NVSЯ так работаю уже лет 7, и ничего :)
просто есть табличка, где все это ведется.
и простым select-ом можно все узнать :)
главное это организовать централизованную выдачу кодов(или каким нить приложением, или один человек должен вести эту табличку)
Делать Вам что-ли нечего? Это просто попытки принизить роль данных БД до пременных прог.
Кому это надо еще и табличку вести, када моно просто более или менее осмысленные имена давать. Ить главная цель БД по максимуму упростить получение нужной инфы. А это все усложнение по любому. Один напишет с крокобякскими именами запрос, второй потом буит искать ошибки, и тратить лишнее время на дополнительные простые SQL, шобы понять шо там за шифрами скрывается, када во многих случаях при нормальных именах этого бы не потребовалось.
Кроме того, СУБД поддерживает коментарии и для таблов и для колонок и из словаря БД моно найти шо за табла и поля и коменты к ним. Зачем еще отсебятинские словари?

NVSvadiminfo,
Зато я точно знаю физический смысл поля IdITM1
и любой другой человек, который придет после меня
не будет догадываться что обозначает:
IdWhouseForStrgOfGdsSntFrSfkpng,
(Warehouse for storage of goods sent for safekeeping - склад для хранения товаров переданных на ответственное хранение)
а просто сделает
SELECT * FROM t_sysName WHERE Name = 'ITM1'
и будет иметь исчерпывающую инфу.
так называемый принцип "вертикальной и горизонтальной прозрачности"
ЗЫ
Я не призываю всех применять этот принцип именования,
но он тоже имеет полное право на жизнь и применение.
Ну я уже говорил, что то кто придет после Вас, если БД в Оракле знает что моно написать типа,
Чтобы узнать про что имя поля


или если 'ITM1' имя таблы

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

Но если бы в имени таблы было Whouse или его сокращения и отсутствовали всякие цифры, то ему было бы проще. Тем более Вы же частично пошли на подсказки включая в имена послова типа DOC. Вы же не стали их называть ITM4, ITM5 и т.д. Теперь ясно что эти таблы связаны с документами любому. Зачем же останавливаться на достигнутом?

NVSдля этого надо ВЕСТИ системные словари, а какая разница, ведете вы системный словарь или свой? Вести его все равно НАДО. Или дескрипшены у полей и таблиц по сигналу из космоса появятся?
А кто придет после меня будет ОБЯЗАН изучить методологию именования объектов базы данных,
ему не надо догадываться, он ОБЯЗАН это знать :)

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


NVS

Да, вот именно, сначала создаются ПРАВИЛА именования объектов базы данных, публикуются
для необходимых людей\организаций.
А потом этим правилам неукоснительно следуют.
И тогда нет разницы как писать
ITM1 или Currency.
Мне удобнее работать с конструкцией типа Преффикс+Номер+Суффикс(
таблица - ITM1, вьюха - ITM1_QR_Sel, СП на инсерт - ITM1_SP_ins
и так для всех объектов базы)
Вам с Венгеркой.
Дело вкуса.

А "неуважение" и прочая... - от лукавого :)
Правила правилам рознь. Разница между ITM1 или Currency великая есть. Не надо знать никаких правил, чтобы догадаться что табла связана с валютой во втором случае. Это облегчает получение инфы (а ить БД для этого и нужны).
Речь не о суфиксах, а о том чтобы в именах была смысловая нагрузка. Вы вот DOC вставили в имена некоторых табл, и если у вас 100 таблов, а нужна инфа про валюту, то эти таблы моно сразу игнорировать, када исчет чел нужную таблу. Уже плюс.
Ваша БД при прочих равных условиях уступает такой же, но с сематичными именами, поскоку интерпритация затруднена. А ить легкость интерпритации данных одно из важных достинств РМД.
Вот и думайте теперь от лукавого это или нет.

NVSЯ это и имел в виду, и не надо мне рассказывать за системные словари, я знаю что это такое.

Ну Вы использовали слово "ВЕСТИ", а системные "вести" не надо, а вести моно тока самаю БД.

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

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



NVS
Однозначно методология.
Каким образом затруднено получение инфы?
кто- то запретит сделать SELECT?

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

Я уже не говорю что для того чтобы пользоваться чисто СУБДшными фичами мало справки по СУБД, нуно еще "методолгические пособия" читать. Ну и зачем это надо?


NVS
да таблиц не 100, гораздо больше, порядка 5000.
Да правильно, смысловая нагрузка, но не венгерская, а по моим правилам, простым и прозрачным
Сначала думаем и вырабатываем методологию :)

У Вас в именах табл маловато смысловой нагрузки. Не тока венры, но и представители многих европейских народов, а возможно и азиатских, будут сбиты с толку.
Думать нуно меньше, а соображать больше (С).

NVS
И не в суффиксах дело, да, в Префиксах, которые и несут основную смысловую нагрузку
да, DOC в моей методологии - это объекты(не таблицы только, в клиенте режим или его составная часть называется также) документооборота(не документы единые!!) ITM - все относится к ТМЦ, SBJ - все что относится к субъектам(люди,склады,партнеры и.т.д)
список можно продолжать до нужных пределов.

Имеют значение тока таблицы - речь о МД. Для клиентов мож имена и нормальные.

NVS
Еще раз повторюсь, ничем не хуже венгерки. ни в понимании, ни в поддержке.
ЗЫ
Мы можем спорить до посинения :),
я уже говорил, дело вкуса..., мне удобнее работать так
а венгерку проходили тоже :),
потом после долгих раздумий таки отказались, повезло, начинали проект с нуля.
Венгерки может и не хуже, хуже БД с семантичными именами таблов и клонок при прочих равных условиях.

Дела не в споре. Просто Вы пошли на излишние ухудшения в плане интерпритации данных. Ну луче Currency, чем ITM1, если в табле по валюту. Ухудшение есть, а выигрыша вроде и нет. Так получается.

NVS
а зачем что-то надо смотреть в системных таблицах?

Не что-то, а инфу про БД. Ну, вообще-то иногда эта инфа имеет значение. Нужно же знать какие объекты в БД, какие свойства. В каких файлах данные. Какие сессии. Кто шо заблокировал. Да мало ли. Так или иначе описание БД обеспечивается СУБД, и польза от этого есть.
Да хоть проверить а есть ли табла в БД? Знает о ней СУБД? Ить то что она в Вашей табличке не означет шо ее не снесли, к примеру.
Я часто работаю с БД с тулсой которая тока позволяет в текстовом редакторе команды языка БД набирать. И без словаря там вообще никуда.

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

В том то и дело, что БД это не просто данные приложения, без которого они не более чем набор байтов. А так моно поставить вопрос зачем Вам вообще таблицы. Хранили бы на диске свои классы в файлах.
У заказчика, например, могут сами писать какие-то отчеты в приложениях предназнченных для отчетов от сторонеего призводителя. Зачем им Ваше приложение?

NVS
не доводите идею до абсурда, все гораздо проще.

Не довожу, а поясняю в чем усложнение. Вы же спрашивали: "кто меншает SQL написать?" Мол если никто то, и усложнения нет. Тада моно спросить: "Кто мешает циклы написать?"
И раз никто, то мол и не сложнее, чем ничего не писать.

NVS
Затем, что если человек собирается работать с приложением, то он должен знать с чем работает
С идеологией, технологиями и методологиями разработки ПО для конкретного продукта.
Или не так?
или мы говорим о продуктах сделанных за одну ночь и забытых?

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

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


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

Разумеется Вы останетесь при своем мнении, поскоку Вы уже за 7 лет более 1000 таблов таких налабали. Теперь поздняк метаться.

Но мы же на форуме, а не в личной переписке. Кто-то третий может тоже выбирать. А Вы как бы идете против очевидности, по не проторенным дорогам, и говорите шо мол все хорошо, мол Вам повезло. И счас толпа проггеров, пришедших к приложениям БД от написания драйверов, с удовольствием последует за Вами, давая имена структурам БД по типу именования переменных прог для управления внешними устройствами. Ну а я, отвечая Вам, типа призываю их проявить разумную осторожность прежде чем безоглядно следовать за Вами. Мол надежнее придерживаться методолгий проетирования из толстых книг по БД.

NVSВот он почитает, подумает и ВЫБЕРЕТ, что ему удобнее, проще автоматизировать и.т.д.
под его конкретную задачу.

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

NVS
А Вы предлагаете ОДИН единственный путь,

Не я предлагаю, а типа хранение информационной модели вместе с данными давно осознали кое-кто поумнее меня. И заточили под это средства поддержки МД. А семантичность модели как бы имеет значение для ее ценности. Чем проще модель понять, тем луче она при прочих равных условиях, в силу самой идеи понятия модель.
Согласно методологиям (в толстых книгах, на лекциях по проектированию) проектирование БД начинают с концептуальной МД. Там нет Ваших табличек еще. Эта МД используется и для согласований в том числе и с заказчиком. И если там крокобякские имена, Вы попросите заказчика почитать Вашу методлогию?
Другие проектировщики от сторонних организаций.
Те кто проектируют ИС начиная с интерфейсов клиентов, по ходу придумывая таблы для хранения перманентных данных этих клиентов, те, да, идут по драйверскому пути. Они, наверное, налабают соответсвующие имена.
Ну им удобнее тада давать имена от проги. Но такой подход несет дополнительные риски для ИС в общем случае.

NVS
SQL не запрещает называть таблицы и поля в моей системе,
и ни один Закон не запрещает, так почему же я должен идти по Вашему пути?
Если я им уже проходил, и на основе своего опыта принял решение отказаться?
и принять свои правила?
SQL и ни один закон не запрещаю вообще не пользоваться СУБД и самим SQL, в частности.
Тока идея SQL - ассоциативного доступа страдает на Вашем пути: с чем могут ассоироваться кракобякские имена?
Одно дело спросить: Выберете валюту такой-то страны. Другое: выберете кергуду такого-то бамбия. А что такое кергуду и бамбия Вы можете узнать в табличке кургуду-бамбия.

Вам отказываться поздняк. Все уже. Но некоторые еще не успели так далеко зайти по этому пути.
Им может стоит по нормальному шоссе двигаться?

NVS
Не возникает двусмысленных ситуаций, если есть правила именования и методология их применения т.е. все систематизировано. А у вас в этом случае просто не было ни правил ни методологии
"Немецкий офицер умеет все, если у него есть инструкция"(С)
А Ваш пример некорректен, мне приходилось приводить другие структуры к моим и наоборот,
нету там двусмысленных ситуаций при вышеописанных условиях. Решается просто и на ура.

Т.е. если есть 10 систем, то нуно читать 10 правил именований и методолгий, чтобы узнать что табла КЕРГУДУ про валюту? Вместо того шобы просто вставить в ее имя Currency? Ить БД прерасположены к интеграции и использованию данных в сторонних системах.
Ну тада есть гимор, который все равно несет риски двусмысленностей.
А мы, например, еще имеем дело с системаи где БД от Финов, Литовцев. И они бы налабали крокобякские, имена и предложили быв читать правила, чтобы расшифровывать имя таблов и колонок? К счастью, они так не сделали. Ниче читать не пришлось для того шобы понять про что таблы.


NVS
Вы попросите заказчика почитать Вашу методлогию?
Лекции это хорошо... Практика другая может быть

К сожалению не тока может, но и бывает совсем другой. Одни придумывают СУБД поддерживающие МД, тратят на это усилия, а другие все делают шобы обесценить эти достижения.

NVS
Если уж на то пошло...
Для начала для всякого приложения разрабатывается

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

NVS
Проектируя БД мы же проектируем не "Сферического коня в вакууме" а что - то конкретное
(учетную систему например), и исходим из требований необходимых для разработки.

Проектируя БД рекомендуется начинать с концептуальной МД. Которой вообще еще по барабану всякие приложения и вообще все компьютерное. К примеру, МД Сущность-Связь. Диаргамма достаточно понятна, выразительна. Ее можно обсуждать и с заказчиком и другими заинтересоваными лицами. Какие имена типам сущностей, связей и атрибутам Вы дадите? Кракобякские? Шобы никто ниче не понял без чтения каких-то там правил и типа методологий?

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

NVS
Имена таблиц и сами таблицы - это реализация, нижний уровень, а не абстрактный набор сущностей, которыми необходимо оперировать при проектировании. И проектируется все это не в конкретной СУБД а в каком нибудь инструменте типа RWin, Rational Rose, Embarcadero Er studio
и им подобным

Наверное, Вы как-то тут не совсем четко сформулировали, что хотели сказать. Но ERwin и позволяет строить диаграммы Сущность-Связь. Которая может использоваться в обсуждениях в том числе и с заказчиком. Т.е. Сущности и связи по сути. Это верхний уровень. Затем преобразовыает в реляционную МД. Имета таблам при этом сохраняются. Вашей таблички с рашифровкой имен там еще нет?
Тбалички относятся к уровню учитывающими компьютерные реализацию, но все же они являются компонентой МД. Т.е. не лишены семантической окраски, если давать им нормальные имена.

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

NVS
например у учетной системы всего 2 основных сущности вокруг которых и крутится все
1 объект учета
2 субъект учета
т.е. мы рассматриваем исключительно жизнь и взаимоотношения этих сущностей.
стрелочками рисуем между квадратиками.

Вот и хорошо. Вот тут и напрашивается дать этим типам этих сущностей семантичные имена.

NVS
Заказчик активно участвует во всем этом процессе, и конечно, читает все методологии, и соглашается с ними или просит предоставить другой вариант.
Не я попрошу прочитать, нормальный заказчик ПОТРЕБУЕТ предоставить методологии :)
Все, завязываем спор. Мне все понятно.
Заказчик читает методолгии? Шутите?
Потребовать то он потребует. Пролистает. Положит в шкаф. Потом буит говорить в частных беседах: вот такую ... они нам присылают.

Так Вы хотели завязать и ранее, а потом вдруг привели якобы новые аргументы.
Суть то простая: Currency семантиченее, чем ITM1. Никакие методолгии этот недостаток Вашей МД, скорей всего, не компенсируют в полной мере.

NVSvadiminfo,
Ну извините, не удержался....

Ничего. Бывает. Хотя бытует мнение, что луче не декларировать уход, если не уверен что уйдешь.

NVS
Currency это частность :)(Валюта, объект учета в роли валюты)
ITM(Item)- общность :) (Объект учета (абстрактный) ) частным случаем которого
и является валюта.

Т.е. тема была про то, как назвать таблы семантично ли по крокобякски. Вы как бы были за второе, но с табличкой расшифровки. А теперь вроде как за первое? Но просто у Вас там модельные сложности: Вы отслеживаете типа иерархию обобщения? Так это к теме отношения не имеет: мы Вашу ПО не обсуждали. Может Вам там вообще таблички не достаточны - нужны объектные типы.
А по теме, если табла не про валюту, а про итемы, то ITM уже выглядит более семантично. Осталось цифры заменить, на что-то более семантичное.

NVS
Если вы не понимаете разницы - это ваша проблема,

Мы про обощения не говорили. Но если Вы понимете разницу, то могли бы пойти и дальше: дать имена Ent1, Ent2, .... Ent - Сущность - еще большая общность чем Итем, скорее всего.

NVS
И нету тут никаких недостатков МД :)

Скорей всего, так просто даже со всякими ухищрениями про обощения от них избавиться не получится. Возможно, нужно еще диалектический метод привлечь на помощь.

NVS

А профессору двойка

Методоло́гия (от греч. μεθοδολογία — учение о способах; от др.-греч. μέθοδος из μέθ- + οδος, букв. «путь вслед за чем-либо» и др.-греч. λόγος — мысль, причина) учение о системе понятий и их отношений, — система базисных принципов, методов, методик, способов и средств их реализации в организации и построении научно-практической деятельности людей.[1]

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