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

Он считает, что первичным ключом таблицы (естественно речь идёт только о суррогатном ключе) должно быть поле, в идеале integer, auto_increment, не использующееся иначе как для связей таблиц.

Я считаю, что допустимо строить первичный ключ с возможностью хранения какой-то ещё характерной информации. Так я делал БД по хранению результатов автогонок. Первичный ключ был столбцом, содержащим год, номер этапа, строку результата. Например 19780603 говорил о третьем результате на шестом этапе сезона 1978 года. Таким образом, как мне кажется, я повышаю целостность таблицы и экономлю место.

Более общие разногласия сводятся к использованию LIKE. Я не вижу в этом чего-то предосудительного, тогда как мой начальник считает, что это не только отрицательно отражается на производительности но и содержит опасность потенциальной ошибки. Возможно дело в том, что он работает с известным своей убогостью MySQL, а я "вырос" на MSSQLServer2000. Я привык использовать язык SQL широко: вводить переменные, строить условия, возможно циклы. Не представляю себе жизнь без представлений и хранимых процедур. Мне интересно ваше мнение по этой проблеме.

Если этот вопрос уже где-то обсуждался, дайте ссылочку.
С Уважением.

ShtockПредлагаю не использовать в таблицах столбцов больше одного строкового типа и в нем хранить сразу же всю информацию........
Он тоже вчера это мне говорил. Я же не анархист. Просто считаю возможность использовать технологии шире, чем это предполагается.

softwarerДля начала стоит таки решить - ключ суррогатный или хранение еще какой-то информации
И то и другое. Он, безусловно, остаётся целочисленным, однако строится по некоторым правилам, позволяющим хранить ещё какую-то информацию.

softwarerбездумное нарушение первой нормальной формы (которое Вы предлагаете) - не лучшая мысль
С точки зрения сервера никакого нарушения нет. Я же не предлагаю делать как говорил Shtock.

softwarerНо для начала надо иметь хороший ответ на вопрос - зачем этот геморрой.
Говоря о примере с результатами гонок - ответ очевиден! Если использовать обыкновенный ключ, придётся добавить ещё два столбца, причём столбец 'year' будет иметь всего-то около 50 различных значений на 15000 записей. А столбец 'round' (1978 06 03) вообще меньше 20! В процессе разработки приложения по генерации статистики на основе такой таблицы я был очень доволен тем, что нужно гнать только один столбец, к тому же элементарно расщепляемый, вместо трёх.

Витал softwarerP.S. Самое интересное, что только вчера объяснял это же довольно опытному MSSQL-щику. Может, конечно, он решил со мной не спорить, но почти сразу согласился.

Дык! Небось это Фрэнки (нштейн) и есть! ;)

Я не "опытный MSSQL-щик" а всего лишь самоучка. У меня нечаяно оказалась отличная книга... так всё и началось.

9Можно узнать сколько места ты сэкономил? Сколько стоит это сэкономленное место?
Сколько в байтах сказать не могу - надо пробовать на конкретных mdf-фалйах. Вот прям на 100% сказать что занимает больше: 2 стобца int(2) или 1 int(4) не могу, но думаю, что первое. Тем более с кучей записей. А насчёт стоимости - да так намного легче работать с данными. Поэтому оно не "стоит", а "даёт".

ShtockВы используете не технологию "шире", а ищете себе геморой. Подумайте о редактировании и о том, как будете парсить Ваш ключ для составления отчетности.
О какой именно отчётности идёт речь?

softwarerЭто, простите, в музей юмора. Сходите в гугль и почитайте, что такое суррогатный ключ.
Я знаю, что это такое. Если бы я говорил о естественном, то сразу бы сделал 3 столбца и определил их ключевыми.

softwarerЭто, простите, также в музей юмора. Во-первых, точка зрения сервера не имеет ни малейшего отношения к 1НФ. А во-вторых, Вы именно это и предлагаете - Shtock только проиллюстрировал подход более ярким примером.
"точка зрения сервера" означает сохраность уникальности значений столбца. Данное поле анализируется только когда это необходимо. Shtock привёл крайность, я же прекрасно понимаю, что стоит за таким применением. Объединение столбцов в моём примере как нельзя логично. Возможно кончено что это "единичный случай", но он имеет место.

softwarerЭто, безусловно, страшно. Теоретикам нормализации, построенной на добавлении столбцов, уготовано место в геенне огненной, не иначе :)
Не надо путать добавление столбцов в таблицу с заменой значений столбца на ключ и создания связанной таблицы 5НФ. Я говорю о том, что бывают случаи, когда бессмысленно расщеплять стобцы. Кстати будет ответить Shtock'у следующим: "давайте сразу создавать таблицы с огромным числом столбцов длины, скажем, 3. Конкатенация это же так просто!"

softwarerОпять-таки один из моих любимых авторов написал по подобному поводу примерно так: "некоторые программисты считают, что мировой запас скобок жестко ограничен, и применять их следует только если без них совсем нельзя обойтись".
Пример хороший, но он скорее к аккуратности кода, повышению его читаемости. Я напрмер ставлю скобки (тут же, полагаю, будут и begin...end;) именно если без них нельзя обойтись.

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

И ещё. 15,000 записей - это вся Формула-1 за 55 полных сезонов. Так что 15,000,000 даже для чемпионата NASCAR, где проводилось в среднем по 40 этапов с 40 участниками на каждом, 1 миллион, не то что 15 - это за гранью разумного.

prof79А если вдруг правила хранения информации изменятся?
Не изменятся. Пока проводится чемпионат, он всегда будет проводится раз в год, в пределах этого года будут этапы (число которых уж точно не перевалит за 99), на которых будут показаны результаты (их число равно числу участников, которых также не бывает и близко к 99. По поводу предметной области можете мне поверить :) ). Если предполагается возможность изменения хранения конечно так делать нельзя!

prof79Если мне не изменяет память 1 НФ утверждает приблизительно следующее:
"Схема отношений R находится в первой нормальной форме. Тогда и только тогда, когда все входящие атрибуты являются атомарными." А Вы предлагаете хранить несколько атомарных значений(год, результат, этап) в одном поле. Что противоречит 1НФ.

Понимаете ли в чём тут дело... Отойдём от первичного ключа. Я долго размышлял над вопросом: вот есть гонщик - "имя фамилия". Но ведь можно расщепить на имя+фамилия? Что это даст? Я пришёл к выводу, что это усложнит выборку, т.к. на каждом шагу придётся соединять эти два столбца. Кроме того, имя и фамилия совершенно очевидно (и это во всех записях) разделены пробелом, поэтому достать при необходимости что-либо проблем не составит. Так и с ключом - где-то расщепляется, а где-то и нет. Есть ведь представления...

2 softwarer, О размере - Спасибо, буду знать...

Скажу ещё кое-что. Раз для всех вас мой спобос - грубая, явная ошибка, то остаётся ещё раз удивится недалёкости наших преподавателей. Ведь эта система является, ни много ни мало, моим бакалаврским дипломом, на отлично защищённым ;)

BolГолосуем!
№1 Начальник всегда прав...
№2 Если он не прав, см. п.№1.
У меня нормальный начальник. С ним можно и нужно вести здоровые дискуссии.

ShtockПример отчетности: да самое простое - Выбрать какие были результаты у команды А в 1997 году.
Эх, не хотел углубляться в предметную область.... видимо придётся. Понимаете ли, что такое "результаты?" В гонках, как пожалуй ни в каком другом виде спорта, можно строить отчёты по таким мудрёным показателям, что даже в голове не укладывается. Так что без разъяснения "результатов" ничего, ровным счётом, сказать нельзя.

ShtockПо поводу преподавателей и бакалавриата....У нас еще была возможность выбрать между инженером и бакалавром.
Не, мы выбирали между инженером и магистром, а бакалавриат - это первые 4 года обучения. Все вместе. А дальше уже либо инженер - полгода учиться + полгода диплом писать (что вообще смешно с нашим уровнем дипломов, подавляющее большинство которых какие-то жалкие системы документооборота в Access, где даже VBA мининум), либо магистр - 2 года обучения (правда только 2-3 дня в институт ходишь), параллельно пишешь диссертацию. Ну я вот пошёл в магистратуру. Хотя основное время уделяю работе.

mir Если хотя бы в потенциале возможны операции над частью атрибута, он не атомарен.
Даже если всего 1-2 раза? Вы утверждаете, что необходимо расщеплять, если есть вероятность использования части значения столбца?

mirВообще, если в запросах часто встречается LIKE, причем это предопределенные запросы , почти 100% - БД спроектирована неверно.
Что такое предопределенные запросы? Те, которые очевидны на этапе проектирования? И почему LIKE это неверно? Не согласен, LIKE - мощная штука, глупо её игнорировать.