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

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

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

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

------

По умолчанию: таблица идет с суррогатным первичным ключом.

Мало того, имена первичных ключей, имена вторичных ключей и типы данных для ключей - регламентированы.

Отсутствие ключа или другие несоответствия - оговаривается дополнительно.

Код пишется под заданную ключами структуру.

Пользовательские поля - отдельно.

городить лишние поля, понимаю, плохой стиль

-----

???

Плохой стиль - это когда надо думать как апдейтнуть запись которая без ключа.

Плохой стиль - это когда надо думать как апдейтнуть запись которая без ключа.

а что толку, если мы имеем такой "ключ", который называется ID, и значений которого нигде кроме этой таблицы не встречается? если уж ключ, так мы должны как-то снаружи таблицы его иметь возможность иметь/получить, иначе какой в нем толк? в моем примере это могло бы быть сочетание датапоездки+автомобиль/водитель+индекспоездки (если предположить, что водитель развозит, например, пиццу, и делает несколько поездок в день. тогда мы знаем дату, водителя (или транспорт), а индексы будем просто перебирать подряд, пока не обнаружим, что запись отсутствует. в таком ключе была бы польза, а просто индекс, которого мы не знаем - не понимаю. или иметь не по одной записи на поездку в таблице, а по одной записи на список поездок за день, тогда и индекс отпадает.

Пару раз натыкался на проблемы с композитными ID-ключами (hibernate, doctrine). С тех пор всегда делаю для таблицы ID.

Мой опыт говорит всегда использовать ID в таблицах. Исключение - таблицы для one-to-many или many-to-many отношений.

1. Для будущего. Добавить ID в начале - дешевео. Добавлять потом, когда надо будет где-то ссылку на запись делать - дорого.

2. "принцип однообразия" (least astonishment) - позовляет хотя бы частично автоматизировать операции с БД

3. разделение между техническим (ID) и логическим (водитель-машина-время) ключом. Логический меняется чаще.

4. ну и скорость / удобство. В MsSQL замена композитного ключа из 7! полей на ID (int) ускорило один сложный select примерно в 20 раз. Вместо 2 минут стал за 5-7 секунд отрабатывать. Писать join-ы тоже попроще становится, да.

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

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

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

Плохой стиль - это когда надо думать как апдейтнуть запись которая без ключа.

В принципе да.

Но если база не особо-большая, то вполне можно обойтис и без ID.

К примеру, если в парке все машины имеют какой-нибудь индивидуальный номер,

к примеру из техпаспорта.

То можно в принципе этим номером и пользоваться.

Только вот проблемка возникает (это для информации ТС).

Если ID может быть 3 - 4 значная,

то номер двигателя или другой номер, обычно это забор из кучи букв и цифр .

Так же как ключь (ID) можно использовать и комбинацию из нескольких полей,

но это вообще геммморой получится.

Так что лучше использовать ID в каждой таблице.

Это упрощает работу и как уже выше Murr сообщил, без ID это плохой стиль.

Вообще, оптимальный вариант, это когда БД соответствует третьей нормальной форме.

ID нужны для связи таблиц по foreign key и генерируются базой на лету (или еще как-то). Никаким водителям их раздавать не надо - поиск так и идет по номеру.

вернусь к моему примеру. для меня в таблице поездок поле ID было бы оправданно в единственном случае, если мы не можем исключить, что захотим иметь таблицу, куда захотим внести ссылку на поездку. во всех остальных случаех этот ID бесполезен. в одном посте на одном из форумов прочел, что человек всегда создает это поле. это имеет то преимущество, что он экономит время на обдумывание решения, нужно оно или нет : )

когда существует связь таблиц - все понятно: в таблице поездок - ID водителя, и по нему быстро ищется водитель в таблице водителей. но если нам нужно найти водителя "снаружи", по фио, то нужно перерыть всю таблицу, причем до конца, а не пока не наткнемся, т.к. ивановиваниваныч может оказаться не уникальным. или должны выучить его ID : )

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

Вы сейчас программную логику обсуждаете?

или всё же ход действий человека, который должен найти этого водилу через программу?

Если первое, то через ID программа найдёт кого угодно.

Если же второе, то человек ищет обычно по дугим критериям,

к примеру по имени или фамилии, или обоим.

ID ему абсолютно не нужны (она используется преимущественно только программой).

Исключение - таблицы для one-to-many или many-to-many отношений.

-----

Есть соответствующие типы реляций - промежуточные таблицы не обязательны.

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

а что толку, если мы имеем такой "ключ", который называется ID, и значений которого нигде кроме этой таблицы не встречается?

-----

И в таблице всего три строки...

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

-----

А разве что-то мешает?

в моем примере это могло бы быть сочетание датапоездки+автомобиль/водитель+индекспоездки (если предположить, что водитель развозит, например, пиццу, и делает несколько поездок в день. тогда мы знаем дату, водителя (или транспорт), а индексы будем просто перебирать подряд, пока не обнаружим, что запись отсутствует. в таком ключе была бы польза, а просто индекс, которого мы не знаем - не понимаю. или иметь не по одной записи на поездку в таблице, а по одной записи на список поездок за день, тогда и индекс отпадает.

-----

Водитель - уволился, машину - списали. Соответствующие записи в таблицах Машины и Водители - удалили.

И это... тебя никто не заставляет пользовать индекс для выборки...

Но это придет с опытом.

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

Предположим мы хотим связать водителя с одной машиной. К одной машине могут быть приписано несколько водителей, водитель всегда только к одной машине. Как мы такое в БД представим? В таблице ВОДИТЕЛЬ будет колонка МАШИНА_ID в которой стоит уникальный ID машины. МАШИНА_ID определена в БД как foreign key ссылающийся на MAШИНА.ID с правилом каскадирования "если на ID есть ссылка, запретить удаление записи из МАШИНА" (DELETE RESTRICT). Позволяет нам на уровне БД добиться целостности данных - не полусится удалить машину оставив водителя, который на ней работать должен.

Представим себе что нам надо поменять номерной знак машины. Перерегистрировали мы ее. Что делать будем?

1. ID машины = номерной знак. Просто UPDATE в том же DB2 не пройдет - иззя менять ключи, на которые ссылается запись. Меняем все записи в ВОДИТЕЛЬ, которые на нее ссылаются, меняем номер, опять меняем все записи теперь с новым номером.
2. ID машины - технический. int. Просто UPDATE с новым номером. Всё.

который мы можем определить ключом в таблице машин

-----

Термин "сурогатный ключ" тебе что-нибудь говорит?

Я вообще плохо понимаю, как можно интегрированность данных поставить в зависимость от введенных пользователем данных.

машины имеют уникальный номерной знак

-----

В пределах страны, надеюсь... ведь границу на машине никто не пересекает...

К тому же, на моей памяти были разные знаки на одной и той же машине и были одни и те же знаки на разных машинах...

вернусь к моему примеру. для меня в таблице поездок поле ID было бы оправданно в единственном случае, если мы не можем исключить, что захотим иметь таблицу, куда захотим внести ссылку на поездку. во всех остальных случаех этот ID бесполезен.

Не только. Изменять значения записи проще имея технический ID (который просто-напросто никогда не меняется). Хотим в гуях иметь возможность скорректировать время поездки. Как искать запись, которой UPDATE делать?

в одном посте на одном из форумов прочел, что человек всегда создает это поле. это имеет то преимущество, что он экономит время на обдумывание решения, нужно оно или нет : )

И это тоже. Однообразность помогает.

Но если база не особо-большая, то вполне можно обойтис и без ID.

-----

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

У меня есть небольшая база - содержит информацию для трансляции внешних документов.

Сколько и каких - Я не знал тогда, не знаю сейчас и не буду знать в будущем - мне

просто пришлют файлик и скажут - Ура, у нас НОВЫЙ клиент... и у него новый

формат документа.

НУ напишу Я то что мне надо для обработки нового документа и будет програмка добавлять

что ей надо в базу. Сколько и чего - Я не знаю. И даже когда будет написано - не буду знать.

Вопрос - как мне починить все это после ошибки оператора - ну вбили что-то не туда и теперь

в выходном документе что-то не соответствует. Ничего не падает, ничего не ломается, просто

на выходе - не то.

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

условный ключ - текстовый, длина 4Кб, содержит смесь фрагментов описаний разных используемых

материалов. Ну вот надо найти "не правильную" запись и поправить. Что Я там буду делать без ИД?

ID ему абсолютно не нужны (она используется преимущественно только программой).

-----

Не просто не нужны, а пользователь никогда не должен их видеть. Вообще.

Бо, это не для него, а для программиста - чтобы не болела голова...

Что Я там буду делать без ИД?

И я про то же.

С ID намного проще.

Я в принципе во всех БД, которые я планирую, всегда в каждой таблице делаю ID.

Даже если и нет особой необходимости, эта колонка облегчает работу.

попалась вот такая интересная читалка:

http://www.agiledata.org/essays/keys.html

ладно, с ID вроде ясно, что ничего не ясно. т.е. нужно смотреть в каждом конкретном случае.

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

я в данный момент делаю небольшой проект(ик), и в качестве базы данных использую .NET System.Data.DataSet class. объем данных ожидаю небольшой (?), справляется нормально пока.

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

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

https://blog.capterra.com/free-database-software/

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

да, никаким комьюнити показывать что-то не собираюсь и продавать продукт не собираюсь. это я, прочитав такое:

you don’t have to pay for MySQL but that still doesn’t that there’s no price.
The price is stated by GNU license under which MySQL community edition is released meaning that you need to reveal you source code under the same terms and give it to the community.
Be aware of that fact if you plan to use for commercial project.

кто-нибудь имеет опыт работы с простыми бесплатными базами? посоветуйте что-нибудь.