Первичный ключ

← →
Jeer © (2006-04-18 17:47) [240]

P.S.
С увеличением числа записей инспектируемой таблицы ситуация будет улучшаться для СК.

← →
vuk © (2006-04-18 17:53) [241]

to euru © (18.04.06 13:47) :

> А Вы, я так понимаю, вместо номера и даты документа предлагаете
> ему какой-то код вводить.

Если нужно именно дату и номер, то надо вводить дату и номер, но дело в том, что обычно интерфейс проектируется так, чтобу вообще это дело свести к минимуму. То есть есть список документов на дату, где можно посмотреть любой документ, найти по номеру в списке и т.п. И ничего не надо вводить руками.

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

Если это нужно, то да, в процедуру формирования списка. Вопрос в том, нужно ли это.

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

← →
Jeer © (2006-04-18 17:55) [242]

vuk © (18.04.06 17:53) [241]

> И ничего не надо вводить руками.

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

← →
Игорь Шевченко © (2006-04-18 18:05) [243]

Jeer © (18.04.06 17:44) [239]

Оно конечно интересно, но отличается тем, что в реальной жизни обычно скорость выборки не является самым существенным критерием, тем более, что железо имеет свойство, согласно закону Мура, каждые 18 месяцев удваивать производительность. Для пущей наглядности неплохо бы показать созданные таблицы для обоих вариантов тестирования, запросы на выборку и их планы, и, собственно, статистику выборки. Разумеется, перед каждой выборкой должен быть очищен кэш сервера базы данных.

← →
Jeer © (2006-04-18 18:14) [244]

Игорь Шевченко © (18.04.06 18:05) [243]

> существенным критерием,

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

> Для пущей наглядности..

Можно, но не нужно:)
Для локального варианта access не так много надо усилий.
А пример таблиц я приводил выше.
Выборки идут по любому сочетанию трех полей (фамилия, имя, отчество)
Индексы есть.

← →
Внук © (2006-04-18 19:29) [245]

>>Игорь Шевченко © (18.04.06 18:05) [243]
>>в реальной жизни обычно скорость выборки не является самым существенным критерием, тем более, что железо имеет свойство, согласно закону Мура, каждые 18 месяцев удваивать производительность
А "лишнее" поле суррогатного ключа, конечно, является непозволительным расточительством ресурсов :)))

← →
Игорь Шевченко © (2006-04-18 21:53) [246]

Внук © (18.04.06 19:29) [245]

> А "лишнее" поле суррогатного ключа, конечно, является непозволительным
> расточительством ресурсов :)))
>

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

Jeer © (18.04.06 18:14) [244]

> Можно, но не нужно:)

Тогда твои миллисекунды тоже ничего не значат :)

← →
xayam © (2006-04-18 22:59) [247]

> Игорь Шевченко ©

> Я бы не сказал, что они такие уж редкие. Почему, интересно,
> авторы книжек по СУБД не рекомендуют, все как один, использовать
> исключительно синтетические ключи ? Они в другом мире живут?

Этот мир называется база данных

> А я еще раз могу повторить про овощи. Про преимущества и
> недостатки уже 195 постов обсуждаем. У естественных ключей
> преимущество в первую очередь в простоте программирования,
> а как ты сам понимаешь, чем проще программировать, тем
> меньше ошибок и тем легче сопровождать систему.

А раз ты это понимаешь, почему же настаиваешь на использовании ЕК, разве что ты и не собираешься делать никакую базу. И заказчики сюда хорошо вписываюся))...

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

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

> Тогда твои миллисекунды тоже ничего не значат :)

это твои аргументы?

> xayam © (17.04.06 23:59) [187]
> > Вопрос был не в том испытывает она проблемы по жизни или
> > нет, вопрос в способности системы (базы данных) к адаптации
> > к изменениям в реальной жизни
> Примеры адаптации в студию. Без примеров твои слова пустой звон.

ага щас

← →
xayam © (2006-04-18 23:03) [248]

> DiamondShark © (18.04.06 13:08) [226]
> А по-моему, по-барабану какой ключ -- естественный или суррогатный.
>
> Лишь бы его значения были атомарными и компактными.

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

← →
xayam © (2006-04-18 23:03) [249]

> Jeer © [239] [240]

+1

← →
Игорь Шевченко © (2006-04-18 23:40) [250]

xayam © (18.04.06 22:59) [247]

> О тебе далеко даже до практики, с теорией бы разобраться,
> что такое нормализация, зачем нужен первичный ключ, что
> такое индекс и как на него влияет присутствие ЕК, ... можно
> долго продолжать

Расскажи, я с удовольствием послушаю.

> А раз ты это понимаешь, почему же настаиваешь на использовании
> ЕК, разве что ты и не собираешься делать никакую базу. И
> заказчики сюда хорошо вписываюся))...

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

> это твои аргументы?

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

xayam © (18.04.06 23:03) [248]

> тебе знакомо слово "нормализация", мало того что он атомарный
> он не должен зависеть...

С этого места подробнее - какое отношение естественные и суррогатные ключи имеют к нормализации ?

← →
xayam © (2006-04-19 00:01) [251]

> Игорь Шевченко © (18.04.06 23:40) [250]

> Расскажи, я с удовольствием послушаю.

извини но честно говорю не люблю болтать

> разумные аргументы

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

> изучи пожалуйста методику проведения тестов

обязательно

> какое отношение естественные и суррогатные ключи имеют к
> нормализации ?

если точнее, то "ключи" и "нормализация". Или у них тоже ничего общего?

← →
Игорь Шевченко © (2006-04-19 00:10) [252]

xayam © (19.04.06 00:01) [251]

> извини но честно говорю не люблю болтать

А зачем тогда ссылаешься на то, о чем не хочешь рассказывать, хотя бы тезисно ?

> их столько было выше, они же тебе не нужны

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

Есть еще желание продолжить дискуссию - милости просим.

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

← →
xayam © (2006-04-19 00:31) [253]

> и естественные и суррогатные имеют право на существования

имеют, никто не спорит, вопрос как раз в простоте использования, поддержки, безопасности (что еще было)

> а исключительно решаемыми задачами и предметной областью

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

← →
Игорь Шевченко © (2006-04-19 00:42) [254]

xayam © (19.04.06 00:31) [253]

> вопрос как раз в простоте использования, поддержки, безопасности

Все зависит от задачи. А то, что проще - я думаю, даже не надо теоремы доказывать.

> да куда ни глянь естественные ключи создают только проблемы
> и ничего не решают

А куда ты глядишь, если не секрет ?

> Да хоть на примере твоих стран, они же не вечны.

Мои страны как раз вечны в рамках стандарта ISO. Как ты понимаешь, даже при прекращении существования страны ее код никакой другой стране не присваивается. Кроме того, если страна прекратило свое существование, то прекратили сове существование и все связанные с ней атрибуты, как то, ее столица, население и тому подобные качественные и количественные характеристики. Так что не вижу причины.

> А если разделишь свою базу на простые сущности, отраж.реальн.
> объект (нормализуешь),

Вот страна и есть реальный объект, куда ее дальше разделять на простые сущности ?

Другой такой же реальный обхект - это город, тоже никуда не разделяется вроде...

Ты все-таки статью почитай, оно интересно.

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

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

← →
xayam © (2006-04-19 00:55) [255]

> А куда ты глядишь, если не секрет ?

секрет))

> Мои страны как раз вечны в рамках стандарта ISO

С какого перепугу, стандарты приходят и уходят, а мы все на форуме

> Как ты понимаешь, даже при прекращении существования страны
> ее код никакой другой стране не присваивается

серьезно? Кто сказал, фамилия имя отчество. И ты ему поверил?

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

невнимательно читал, приводили хороший пример с номерами от машины. А что если стандарта не будет, то не будет и страны? Стандарт это только один из атрибутов.

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

хочу быть голословным (пример выше)

← →
Игорь Шевченко © (2006-04-19 01:11) [256]

xayam © (19.04.06 00:55) [255]

> С какого перепугу, стандарты приходят и уходят, а мы все
> на форуме

Дорогой друг, ты вообще в курсе, зачем вводятся стандарты ? Я тебе намекну - стандарты вводятся для того, чтобы сформировать общее одинаковое представление о какой-либо сущности. Так вот, в связи с этим, стандарты ISO в части кодировок стран и прочей географии служат для того, чтобы сформировать общее представление, от том, что под кодом UA подразумевается страна Украина, а не Острова зеленого мыса. То есть, это тоже близко к суррогатному ключу, в конце концов, для стран все ключи будут суррогатными, но этот ключ, который однозначно определяет страну во всех базах данных, в которых принято использовать этот стандарт. И при обмене данными с китайской базой, например, все ID идут лесом и надолго, потому что ID однозначно будет идентифицировать сущность только в конкретной базе данных. Название тоже идет лесом, потому что в китайской базе оно, соответсвенно, китайское, а в украинской, сам понимаешь, украинское. И поэтому, для однозначной идентификации используется именно ОБЩИЙ СТАНДАРТНЫЙ ключ.

> серьезно? Кто сказал, фамилия имя отчество. И ты ему поверил?
>

Поверил. И тебе советую поверить, он еще ни разу не врал. Фамилия имя отчество - International Standard Organization, немного непривычно, но это только вначале.

> невнимательно читал, приводили хороший пример с номерами
> от машины. А что если стандарта не будет, то не будет и
> страны? Стандарт это только один из атрибутов.

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

← →
xayam © (2006-04-19 01:24) [257]

> чтобы сформировать общее одинаковое представление о какой-
> либо сущности

у меня не сформировалось, может у кого тоже

> International Standard Organization

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

> Если стандарта не будет, то ты страну не опишешь

Запросто - Россия

> Даже название страны тоже является стандартом, как ни странно

а я о чем вчера СССР, сегодня РФ. Как поменяли? Это же стандарт, не сформировалось видно...и у них тоже

← →
Игорь Шевченко © (2006-04-19 10:12) [258]

xayam © (19.04.06 01:24) [257]

> у меня не сформировалось

Видишь ли, организация ISO не ставит своей целью сформировать именно твое представление.

> Запросто - Россия

Объясни это говорящим на других языках. По крайней мере у тебя будет чем время занять.

> а я о чем вчера СССР, сегодня РФ. Как поменяли?

Ничего не меняли. СССР было SU, Россия - RU. Никаких проблем для того, чтобы отличить, нету.

← →
Jeer © (2006-04-19 10:21) [259]

Игорь Шевченко © (18.04.06 21:53) [246]

> Тогда твои миллисекунды тоже ничего не значат :)

Миллисекунды всегда значат больше, чем чье-либо особое мнение.

← →
Игорь Шевченко © (2006-04-19 10:30) [260]

Jeer © (19.04.06 10:21) [259]

> Миллисекунды всегда значат больше, чем чье-либо особое мнение.

В том случае, если они воспроизводимы, не так ли ?

← →
Jeer © (2006-04-19 10:33) [261]

разумеется, иначе это лженаука:))

Но мне кажется, что лично тебе не интересно ковыряться с такими "мелочами",
т.к. ответ изначално тебе известен.

← →
Игорь Шевченко © (2006-04-19 10:53) [262]

Jeer © (19.04.06 10:33) [261]

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

← →
Lamer@fools.ua © (2006-04-19 10:58) [263]

>В программах для меня важна в первую очередь простота, во второую очередь сопровождабельность...

"Доктор, у меня такое впечатление, что меня все игнорируют" ©
На [200] можно узнать ответ?

← →
Sergey13 © (2006-04-19 11:00) [264]

2[262] Игорь Шевченко © (19.04.06 10:53)
>В программах для меня важна в первую очередь простота, во второую очередь сопровождабельность и лишь в третью очередь - производительность.

Интересная позиция. Другими словами - лишь бы мне было хорошо, а юзер нехай загнется. 8-)

← →
Jeer © (2006-04-19 11:10) [265]

> В программах для меня

Может в этом все дело ?
Ограниченный спектр ПО ?

Для меня важными остаются приоритеты:
- скорость разработки (без унификации это сложно, а если Заказчик на ходу меняет предпочтение в СУБД и такое бывает ?);
- удобство пользования (интерфейс и производительность);
- удобство сопровождения (чаще всего это вынужденные изменения во внешней информационной среде, а это уже доработка);

← →
Игорь Шевченко © (2006-04-19 11:14) [266]

Lamer@fools.ua © (18.04.06 11:07)

> Почему, когда я пишу JOIN в запросе, я должен вспоминать,
> по какому полю (или, упаси Аллах, полям) мне нужно соединять
> таблицы в ON?

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

← →
Игорь Шевченко © (2006-04-19 11:20) [267]

Jeer © (19.04.06 11:10) [265]

> Ограниченный спектр ПО ?

Разумеется, ограниченный. А как иначе ? Необъятное не обнимешь, как ни старайся.

> - скорость разработки (без унификации это сложно, а если
> Заказчик на ходу меняет предпочтение в СУБД и такое бывает
> ?);

Сергей, дело в том, что если заказчик меняет предпочтение в СУБД, то в моем случае у меня одним заказчиком автоматически становится меньше. Потому что переделывать всю серверную часть (а это не только таблицы), нанимать специалистов со знанием предпочтенной заказчиком СУБД, просто невыгодно экономически.

> - удобство пользования (интерфейс и производительность);

Это со структурой базы, как ты сам понимаешь, не связано.

> - удобство сопровождения (чаще всего это вынужденные изменения
> во внешней информационной среде, а это уже доработка);

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

← →
Lamer@fools.ua © (2006-04-19 11:22) [268]

>>Игорь Шевченко © (19.04.06 11:14) [266]

>какие таблицы тебе надо соединять или какие из них поля надо выбирать и по каким критериям ограничивать выборку
Ну это мне придётся помнить в любом случае, не так ли?

Lamer@fools.ua © (19.04.06 11:22) [268]

> Ну это мне придётся помнить в любом случае, не так ли?

Ну да, конечно. А поля во всех таблицах для всех связок у тебя одинаково называется во избежание склероза ? :)

> то в моем случае у меня одним заказчиком автоматически становится
> меньше.

Значит это будет мой Заказчик, т.к мне все равно - какая СУБД.:))

> Это со структурой базы, как ты сам понимаешь, не связано.

Производительность связана и со структурой и с движком.

> когда в программе не введено лишних сущностей.

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

P.S.
Я понимаю, ты резко занятый человек, но вот возьми мой примерчик и проверь и нам будет интересно - совпадение или нет результатов в разных географических регионах.

>А поля во всех таблицах для всех связок у тебя одинаково называется во избежание склероза ? :)

Возможно Вы поставите ещё мильон смайлов, но вообще-то да. Точнее не одинаково, а единообразно.

CREATE TABLE [dbo].[tbe_Address] ( [Id] [int] IDENTITY (1, 1) NOT NULL PRIMARY KEY, [AddressLines] [ntext] NOT NULL, [City] [nvarchar] (128) NOT NULL, [CountryId] [int] NULL, [ZipCode] [nvarchar] (128) NOT NULL ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO CREATE TABLE [dbo].[tbe_Contact] ( [Id] [int] IDENTITY (1, 1) NOT NULL PRIMARY KEY, [AddressId] [int] NOT NULL, [EMail] [nvarchar] (128) NOT NULL, [FaxNumber] [nvarchar] (128) NOT NULL, [MobilePhoneNumber] [nvarchar] (128) NOT NULL, [Name] [nvarchar] (128) NOT NULL, [PhoneNumber] [nvarchar] (128) NOT NULL ) ON [PRIMARY] GO ALTER TABLE [dbo].[tbe_Address] ADD CONSTRAINT [FK_tbe_Address_CountryId_tbe_Country_Id] FOREIGN KEY ( [CountryId] ) REFERENCES [dbo].[tbe_Country] ( [Id] ) GO ALTER TABLE [dbo].[tbe_Contact] ADD CONSTRAINT [FK_tbe_Contact_AddressId_tbe_Address_Id] FOREIGN KEY ( [AddressId] ) REFERENCES [dbo].[tbe_Address] ( [Id] ) GO

>>Игорь Шевченко © (19.04.06 11:26) [269]
>>А поля во всех таблицах для всех связок у тебя одинаково называется во избежание склероза ? :)
Само собой. Имя_таблицы+ID. Я уже намекал на построение скрипта базы Case-средствами. Если это религия, то ... Будешь обзываться - я отвечу адекватно :)

OFFTOPIC:
Не понял. Почему в [271] пробелы "съелись"?

Jeer © (19.04.06 11:30) [270]

> Значит это будет мой Заказчик, т.к мне все равно - какая
> СУБД.:))

Это вряд ли :) Среди списка своих конкурентов я тебя не наблюдаю :)

> Производительность связана и со структурой и с движком.

Только отчасти. Абстрактная производительность она чаще всего не играет важной роли. Играет роль время реакции системы.

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

А я бы с удовольствием, если ты скрипт напишешь. Только Access и MSSQL у меня нету. Есть Firebird (Interbase)

> Играет роль время реакции системы.

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

> скрипт напишешь.

ок

← →
Sergey Masloff (2006-04-19 11:45) [278]

← →
Sergey Masloff (2006-04-19 11:46) [279]

к Sergey Masloff (19.04.06 11:45) [278]
Ну в смысле Имя_таблицы+ISN

Sergey Masloff (19.04.06 11:46) [279]

Я о конкатенации:)

Первичный ключ Найти похожие ветки