Игорь1973Добрый день.

В базе данных много таблиц, у каждой есть ключевое поле, которое называется "ID". И это одинаково для каждой таблицы.
Поля-внешние ключи все именуются по такой схеме "ProductID", "ClientID", "UserID"...
Т.е. ключевые поля и поля-внешние ключи не одноименны.
Но вопрос не в этом, а в том - как лучше называть все эти поля по-русски в интерфейсе программы?
Можно так "Код" и соответственно "Код продукта", "Код клиента", "Код пользователя"...
Но я уже неоднократно видел в других системах, что часто называют "Ид" и "Ид продукта", "Ид клиента", "Ид пользователя"...
Вроде бы, в MS Navision или Axapta так. "Ид" немного короче чему "Код" (на одну букву), но может быть менее понятен незамысловатому пользователю. А что вы думаете по этому поводу?

Заранее спасибо за ваш ответ.

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

Евгений Мирошниченко aka mirБредятинаИменовать и описывать характеристики объектов нужно на родном языке на уровне БД, а не приложения. Более того, приложения баз данных вообще не должны программироваться, они должны проектироваться. Для этого нужно просто использовать СУБД. Вы же, вероятно, используете какую-то "реляционную систему", которая СУБД не является:)
Никак Андрей Леонидович! Жив, курилка! И до сих пор не в курсе про трёхуровневую модель ANSI/SPARC...
Не стоит ёрничать. Вы уже многое усвоили. Но с метаданными и семантикой пробелы еще есть:) Все еще впереди. Так что не отвлекайте людей от существа вопроса. "Трёхуровневая модель ANSI/SPARC" не поможет Вам обосновать хранение метаданных в приложении:)

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

Евгений Мирошниченко aka mirБредятинаНе стоит ёрничать. Вы уже многое усвоили. Но с метаданными и семантикой пробелы еще есть:) Все еще впереди. Так что не отвлекайте людей от существа вопроса. "Трёхуровневая модель ANSI/SPARC" не поможет Вам обосновать хранение метаданных в приложении:)
Почитайте что-нибудь по теории БД, наконец. В частности, про трёхуровневую модель ANSI/SPARC. Это поможет вам понять, что умные люди уже почти полвека назад решили вопросы, о которых вы только-только задумываетесь на дилетанском уровне.
Вы знаете, я раньше пессимистично смотрел на эту странность - нежелание специалистов в области "реляционных систем" обсуждать вопросы по существу. Но теперь я оптимист, именно потому, что "реляционные СУБД" не являются СУБД, и у Вас просто нет ни знаний, ни опыта, чтобы что-то обсуждать по существу в области баз данных. Я Вам цитирую существо "трехуровневой модели", но Вам нечего сказать, и, конечно, приходиться переходить на личности:) Соболезную:)

Евгений Мирошниченко aka mirРечь может идти лишь про убогость его понимания теории и практики систем БД.
Пожалуйста, попытайтесь обсуждать вопрос по существу. Например, когда MS реализовала возможность русскоязычных полей таблиц, а очень ясно объяснил почему это бессмысленное решение, которое не может быть востребованным. Говорите по существу, и у Вас просто прибавится знаний в области БД. Разве это плохо? Даже при том, что я плохой:)
Евгений Мирошниченко aka mirМозги есть только у людей, и только люди понимают концептуальную схему и прочее. Ни у какой системы нет мозгов и никакая система ничего не понимает. Вот такая правда жизни. Что касается концептуальной схемы. Уровень абстракции в ней выше, что удобно для концептуального проектирования, но и возможностей меньше, что неудобно для детального проектирования.
Это просто неправда. Вы никогда не использовали модель данных, которая обеспечивает фактическое слияние концептуального и логического уровней. Вы рассуждаете о том, чего принципиально не знаете. А я знаю реляционные системы не хуже Вас:) Понимаете в чем разница, и в чем Ваша проблема?:)
Евгений Мирошниченко aka mirТо есть во многих простых случаях из концептуальной можно однозначно получить физическую модель, но не всегда, есть ситуации, в которых концептуальной моделью не всё можно описать.
Рекомендую Вам никогда не использовать в обсуждениях такого рода словосочетание "физическая модель". Это Вас сильно запутывает, поскольку Вы постоянно путаете логическую модель с физической.
Евгений Мирошниченко aka mirА есть аспекты, в которых концептуальной моделью почти ничего нельзя описать, это сложные ограничения целостности, вовлекающие несколько сущностей (или таблиц, если для РМД). В концептуальной модели можно описать только простые ОЦ уровня атрибута и некоторые специальные ОЦ, но не сложные ОЦ произвольного вида.
Зачем Вы написали эту очевидную вещь. Не все ОЦ можно описать декларативно. И РМД (логическая модель) здесь ничем абсолютно не может помочь.
Евгений Мирошниченко aka mirОткрою секрет, операторы Union, Join и т.д. предназначены для манипулирования, а не проектирования, поэтому модельер их вообще-то и не видит. Как раз тот случай, когда модельер должен иметь дело с операторами, это описание сложных ОЦ. Но без этого не обойтись, т.к. условие нужно явно сформулировать и никакая система за модельера этого не сделает.
Хорошо, что Вы это подтвердили:)