На моей новой работе юзают много разных БД  

Так вот
(1) в базах часто используются таблицы у которых PrimaryKey состоит из 3-х ,5-ти, а то и 7-ми полей.
(2) а ещё  есть таблицы с 20-30 полями.
 
Моё мнение:  ето бардак - плохо спроектированые БД

В универе нас препод учил что ето не есть хорошо 
Да и в книге "Конноли Т., Бегг К. Базы данных: проектирование, реализация и сопровождение."(читал года два назад)я кажись неппомню чтобы рекомендовали такое

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

Вопрос:
Так рекомендуется или не ракомендуется юзать составные PrimaryKey?
Люди поделитесь своим  опытом! Неужели у вас тоже встречаются такие таблицы(с (1) и (2)) 

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

Но иногда составной PK бывает и полезным. В частности: уникальный ID записи для всех таблиц базы, или даже уникальный в пределах нескольких баз (нужно для репликации данных). Или вынести в PK некое условие, по которому часто осуществляется фильтрация данных.

если есть составной ключ из нескольких полей, то лучше (в целях оптимизации и удобочитаемости)
завести таблицу соответствий простой ключ <--> составной ключ
и вместо составнго юзать соответствующий ему простой...

потенциально - плохо; но лучше смотреть "по ситуации". У меня немало таблиц с PK на два поля. 

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

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

Везде, где работал, на больших продакшнах именно так и делали.
Но это лишь моя точка зрения 

Lamak, очень многое зависит от проекта и его назначения.
Есть проекты, в которых невозможно обойтись без составных ключей (та же репликация), есть проекты, в которых таблицах которых нужны именно 20-30 полей (например детальные анкетные данные о человеке - адрес, телефон, дата рождения - человек один, разбивать на мелкие таблички не нужно)
В общем, я считаю, что ты слишком пытаешься обобщить ситуацию под теорию.
Разберись в сути проектов и приведи более детальный пример - тогда можно будет говорить более конкретно.

Это сообщение отредактировал(а) Shiny - 6.11.2006, 12:27

Вобщем, 


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


А вот тут следует хорошо подумать:


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

Иногда следует применять вертикально разбиение таблицы:
ФИО, паспорт, некий код etc. - держать в первой таблице.
Во вторую вынести год рождения, адрес,  дату регистрации, прописку, семейное положение и прочую мелочь. Связать их отношением 1 к 1 по искусственному примари ки.

Если 90% запросов - просто список людей без дополнительных данных - скорость возрастёт.
А остальные 10% запросов вполне могут делать джоин этих таблиц в одну.
Опять-таки, можно посадить вьюху, которая будет представлять как бы неразбитую таблицу джойном.

Вполне возможно, что стоит разбить таблички для скорости....

Тутачки немного написано по этому поводу 

Опять же - зависит от проекта.
У меня одинаково часто запрашивали инфу как по параметрам "пол-возраст", "город - месяц рождения", "тип населённого пункта - наличие домашнего телефона" и т.д. и т.п.
Заморачиваться с разделением не стоило - никакой выгоды не вижу, приоритетные поля выделить нельзя.
Поэтому всё равно считаю что всё зависит от конкретного проекта 


Составной праймари кей необходимен для правильной обработки данных, полученных с реплицированных баз. Служебный АйДи(ГУИД) добавляет сам сервер, но использовать его для последующего анализа нереально - это всё равно что varchar(16), скорость обработки нулевая.... 
Другое дело что потом для правильной работы того же олапа нужно делать из 4-х полей составного ключа одно уникальное вычисляемое поле, а это уже кто как исхитрится 

Ессно 
(

)



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

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

Согласна - работает для всех НЕреплицируемых баз.
Для них можно даже и на сервер положиться - айдентити при отсутствии репликации меня ещё не подводило.
Для реплицируемых - фикус 

Угу 

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

TaNK,  Что значит "не слишком много"? И что значит "с InterBase хвататет и пару ключей, один PK и парочку FK"? Чем этот сервер БД так уж отличается от всего остального?
На таблицу может быть один PK. И желательно, чтобы он всегда был. Иначе потом будет немного больно ;)
Идея, что нужно иметь в первичный ключе одно поле, и при этом автоинкремент, пришла из файловых БД - там за целостностью ручками следить надо было. 
Естественно, искусственные ключи нужны. Но и составные - тоже нужны, в связке мастер-деталь. У меня иногда получается иерархия до 4-5 деталей, последовательно, т.е. Мастер -> Деталь -> Деталь ... И если бы я делал в каждой детали простой ключ из одного автоинкрементного поля - ну это просто нарушение целостности! Как понять, какому мастеру принадлежит деталь N-го уровня?! 
Я считаю, что уж идентифицирующая связь должна приводить к автоматическому наследованию PK мастера в PK зависимой таблицы. И такие соображения, что индексы получаются объемными тут, имхо, вообще не должны приводиться: нормальная БД справится. Зато запросы будут гораздо проще.

1. При чем тут нарушение целостности? foreign key на что?
2. Если в середине этой цепочки один child сменит parent-а, то всю нижележащую цепочку править?

Нарушение логической целостности: глядя на запись подчиненной таблицы можно определить только запись непосредственного предка. 
То есть, я имею в виду случай, когда 
1. имеется иерархия подчинения
2. на каждом уровне первичный ключ - простой уникальный идентификатор
3. имеется ссылка только на непосредственного предка.
И получается, что для того, чтобы найти группировку более высокого уровня, требуется пройти всю цепочку. А если ключ наследуется по порядку - четко видно всю иерархию, и промежуточные уровни можно опускать.
При этом возникает два случая:
а. Связь по альтернативному ключу. Зачем? Как раз лишний индекс и образуется.
б. Связь неидентифицирующая (в детали ссылка на мастера не входит в первичный ключ). Но это же совсем не то, что подразумевалось! Это - не связь мастер-деталь, это лукап.

А насчет смены парента - вообще говоря, идентифицирующая связь не предполагает этого. Например, возьмем простой документ, счет, состоящий из заголовка и содержимого. Явная связь мастер-деталь. И пересоединять содержимое документа к другому заголовку - достаточно бессмыссленная операция.
Разумеется, бывают и другие случаи - но в этих случаях смена парента - редкая операция, тут можно и поправить. Тем более, что и делать-то ничего не надо особо: констрейнт обновит автоматом.

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