Primary Key performance

Возьми да померяй.
И вот это почитай: http://stackoverflow.com/questions/517579/strings-as-primary-keys-in-sql-data...

Сильно ли различается производительность если в качестве Primary Key использовать строку а не число

Сильно. Особенно если это varchar, а не char. В качестве ключей(хоть первичных, хоть внешних) ничего кроме целых чисел лучше не использовать.

Аналогично int/bigint сильно влияет на производительность?

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

как в машине может храниться

И сравниваться

У меня на тестовой таблице с 5000 записей разница вообще не видна.

(Что использовал: скрипты для генерации таблиц (https://gist.github.com/1964920 ), mysql, pwgen).

5000 записей
разница вообще не видна.

На целых 5000 записей с такими-то сложными данными?

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

PS. Как мы все знаем - преждевременная оптимизация - зло.

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

Мне кажется, что стоит поинтересоваться у ТС.

PS. Как мы все знаем - преждевременная оптимизация - зло.

Зло - это проектирование системы человеком не в теме. Остальное сказки.

Кстати да, кастую ТС для дополнительной информации. Какие объемы БД примерно, на сколько сложные запросы будут, чем ему не нравится синтетический PK, какая СУБД/движок будут использоваться? Без всего этого все ответы в этой теме - гадание на кофейной гуще.

Проблема в тебе а не в PK. Ты решаешь ее костыльно.
http://en.wikipedia.org/wiki/Slug_(web_publishing)

Кстати, я хотел предложить ТС просто делать выборку по полю username, но он же хочет PK :/

Вот и я спросил, почему не подходит синтетический PK.

Как мы все знаем - преждевременная оптимизация - зло.

А когда система загнётся от неожиданно подскочившей нагрузки это не зло? Уж лучше всё как следует продумать, хотя бы постараться как можешь оптимизировать. То что я не являюсь экспертом в проектировании баз данных очевидно из топика, однако если не разбираться, не задавать вопросы, не пытаться оптимизировать так никогда не станешь экспертом. Любой эксперт начинал когда то... Гораздо хуже когда быдлокодеры пишут кое как не задумываясь ни о чём.

Кстати хорошо что вспомнили wikipedia. Там же используется этот slug и объёмы данных огромные. Значит так можно делать даже с такими объёмами данных. Хочется уточнить, может какие то ньансы оптимизации они применяют. В статье о производительности ни слова.

Делать выборку по полю и по текстовому PK дадут разную производительность? Или вы имеете ввиду что производительность упадёт из за текстовых foreign key в других таблицах?

Можно подробнее, что имеется ввиду под «синтетическим PK»? PRIMARY KEY (id, username) что ли?

В качестве RDBMS будет скорее всего PostgreSQL но рассмотрю и другие варианты. Определяющим критерием является надёжность в плане невозможности занести некорректные данные. MySQL с ёё наплевательским отношением к этому плохо подходит. Есть конечно SET sql_mode = 'TRADITIONAL' и др. но как то это выглядит ненадёжно как костыли.

А когда система загнётся от неожиданно подскочившей нагрузки это не зло? Уж лучше всё как следует продумать, хотя бы постараться как можешь оптимизировать. То что я не являюсь экспертом в проектировании баз данных очевидно из топика, однако если не разбираться, не задавать вопросы, не пытаться оптимизировать так никогда не станешь экспертом. Любой эксперт начинал когда то... Гораздо хуже когда быдлокодеры пишут кое как не задумываясь ни о чём.

В подтверждение своей точки зрения могу дать взгляд CEO компании компании PostgreSQL Experts Inc.: http://habrahabr.ru/blogs/sql/107834/ . Собственно, вот:

Производительность. Обычно плохая причина. Да, действительно, могут возникать ситуации, в которых использование естественных ключей сильно замедляет работу системы по сравнению с суррогатными. Но в 80% случаев за этим утверждением не стоят реальные тесты и подобное утверждение остается безосновательным. Предварительная оптимизация – корень многих бед в дизайне баз данных.

Делать выборку по полю и по текстовому PK дадут разную производительность? Или вы имеете ввиду что производительность упадёт из за текстовых foreign key в других таблицах?

Я имею в виду, запросы будут простыми (select from where) или же сложные (с джойнами, хранимыми процедурами, етц)?

Можно подробнее, что имеется ввиду под «синтетическим PK»? PRIMARY KEY (id, username) что ли?

Как оказалось, правильно говорить суррогатный ключ. Но да, суть понята правильно.

В качестве RDBMS будет скорее всего PostgreSQL но рассмотрю и другие варианты. Определяющим критерием является надёжность в плане невозможности занести некорректные данные. MySQL с ёё наплевательским отношением к этому плохо подходит. Есть конечно SET sql_mode = 'TRADITIONAL' и др. но как то это выглядит ненадёжно как костыли.

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

Алсо, если хочется тупо производительности, в ущерб удобству разработки - то лучше использовать noSQL решения. Но мне кажется, что это действительно лишнее.

Алсо, если хочется тупо производительности, в ущерб удобству разработки - то лучше использовать noSQL решения. Но мне кажется, что это действительно лишнее.

Это сразу отметается. Во первых на мой взгляд это всё на уровне экспериментирования а для production лучше проверенный годами использования SQL. Во вторых поддержка транзакций там минимальная, гарантии data consistency тоже. Для некоторых случаев хорошо конечно. Делал недавно проект где заказчик настоял что бы юзеры хранились в MySQL а сообщения в MongoDB т.к. якобы система должна иметь возможность хранить разные типы сообщений с разными атрибутами. Мне кажется это маразм, можно всё реализовать using one-to-many relationship и хранить дополнительные атрибуты сообщения в отдельной таблице. Но спорить не стал, сделал и получил оплату кстати неплохую. Предупредил его о возможных проблемах.

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

shared hosting'и рассчитаны разве что на мелкие бложики с 5 посещениями за неделю. Использовать для чего то другого глупо.

Как оказалось, правильно говорить суррогатный ключ. Но да, суть понята правильно.

Мне непонятно зачем в PK включать ещё и username. Можно же просто INDEX зделать на username а в FOREIGN KEY ссылаться на id. Насколько я понял для ускорения выборки по полю надо делать INDEX на нём который PK добавляет автоматически.

Я имею в виду, запросы будут простыми (select from where) или же сложные (с джойнами, хранимыми процедурами, етц)?

Будут с джойнами но не особо укуренные. Где вы видели веб приложение сложнее helloworld'а где бы не требовались джойны.

А по поводу процедур мне кажется эффективнее вызвать процедуру чем 10 отдельных запросов. Разве нет?

Это сразу отметается. Во первых на мой взгляд это всё на уровне экспериментирования а для production лучше проверенный годами использования SQL. Во вторых поддержка транзакций там минимальная, гарантии data consistency тоже. Для некоторых случаев хорошо конечно. Делал недавно проект где заказчик настоял что бы юзеры хранились в MySQL а сообщения в MongoDB т.к. якобы система должна иметь возможность хранить разные типы сообщений с разными атрибутами. Мне кажется это маразм, можно всё реализовать using one-to-many relationship и хранить дополнительные атрибуты сообщения в отдельной таблице. Но спорить не стал, сделал и получил оплату кстати неплохую. Предупредил его о возможных проблемах.

Тем не менее, noSQL решения находят свою нишу - twitter, mail.ru тому пример. Так что, постепенно они переходят из эксперементальной стадии в продакшн.

shared hosting'и рассчитаны разве что на мелкие бложики с 5 посещениями за неделю. Использовать для чего то другого глупо.

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

Мне непонятно зачем в PK включать ещё и username. Можно же просто INDEX зделать на username а в FOREIGN KEY ссылаться на id. Насколько я понял для ускорения выборки по полю надо делать INDEX на нём который PK добавляет автоматически.

Фразу выше не правильно понял =/ То, что было в примере выше - это составной PK. Я имел в виду, что тот самый id (который PK, autoincrement) - суррогатный ключ. Собственно, сам вопрос в топике, если я правильно понял, сводится к тому, правильно ли использовать суррогатные ключи. А этот вопрос довольно холиварен сам по себе и, как мне кажется, единого мнения тут быть не может. В приведенной мной выще ссылке на хабр как раз затрагивается этот вопрос. И там же говорится, что в большинстве случаев производительность сильно проседать не будет. В любом случае, я бы протестировал производительность в одном и другом случае, это даст наиболее полное представление о том, что использовать эффективнее.

И да, cast KRoN73

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

А, вообще, от конкретных задач зависит.

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

Ну когда поиск по индексу идет, то индекс из целых чисел и состоит, неважно по полю какого типа? Я думал что так. Ну и мои тесты производительности показали, что на моих данных нет разницы.

Сильно ли различается производительность если в качестве Primary Key использовать строку а не число, например:

Зависит от запросов. Если поиск на сравнение, то разницы нет, если выборка диапазона, то разница существенна. Но primary key делать строковым это дурной тон.

Аналогично int/bigint сильно влияет на производительность?

Если индекс помещается в память, то не влияет.

PS. Как мы все знаем - преждевременная оптимизация - зло.

преждевременная грубое занижение производительности зло ещё большее.

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

Вобще для >80% случаев можно считать, что индекс должен быть INT/BIGINT.