Игорь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 и т.д. предназначены для манипулирования, а не проектирования, поэтому модельер их вообще-то и не видит. Как раз тот случай, когда модельер должен иметь дело с операторами, это описание сложных ОЦ. Но без этого не обойтись, т.к. условие нужно явно сформулировать и никакая система за модельера этого не сделает.
Хорошо, что Вы это подтвердили:)

Евгений Мирошниченко aka mirВ своё время Чернышов Андрей Леонидович, который Бредятина, круто опозорился здесь именно на попытке дать определение навигации (которая противопоставляется как раз декларативности).
Круто опозорились оппоненты Чернышева Андрея Леонидовича. В основном, из-за неспособности (видимо органической:)) обсуждать вопросы по существу. Что Вы лишний раз продемонстрировали и в этой теме:)

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

ViPRosvadiminfoв нем говорится ЧТО надо, но не говориться КАК. Например: Найти всех сотрудников, у которых зарплата меньше 100 000 р. Здесь есть что надо, но нет ничего о том как это буит.

как раз СКЛ так НЕ работает
он требует детализации понятия Сотрудник (всякие фромы и джойны) и Зарплата (хранимая процедура, функция и т.д.)
SELECT a, вместо SELECT a FROM b, выдвигает определенные требования. Вопрос: к модели или к реализации модели?
Найти применение для SQL довольно не просто. Я на фактах показал, что SQL бесполезен (точнее, вреден) для большинства задач (например, для систем класса ERP). Так же я приводил пример, когда алгебра идет рука об руку с семантикой, и оказывается полезной:)

Евгений Мирошниченко aka mirViPRosЕвгений Мирошниченко aka mir,

ты препод что ль?
поставить задачу в моем понимании - задать цель и указать ограничения
Ваш "ответ" вопросом на вопрос показывает, что ответить вы не можете. Ни в целом, ни для конкретного примера. Что и требовалось доказать.
Понятно, ViPRos, что здесь требовалось доказать?:) А Вы все про базы данных рассуждаете:) Ваши ответы будут умышленно игнорироваться, чтобы "доказать", что ответить не можете:)

Евгений Мирошниченко aka mirа в диалекте Sybase есть KEY JOIN, который именно по внешнему ключу и соединяет.

По какому из трех?:)