то есть какой-нибудь там Linked In вполне может такое использовать?

и это будет оправдано?

даже я это могу использовать, хоть я и не линкед ин

когда ты понимаешь риски апдейт аномалий ради производительности

все действительно примерно к этому сводится

В реальных проектах не 3 таблицы а обычно 333. Поэтому потребность в денормализации возникает раньше чем на 10 миллионах пользователей

при каком количестве кортежей в этих таблицах такие методы оправданы?

у вас какие-то безумные вопросы

Если кортежей больше или равно 1928746

?

Павел ответил раньше, чем я спросил)

при каком количестве кортежей в этих таблицах такие методы оправданы?

в тот момент, когда становится очевидно, что джойны начинают душить

в тот момент, когда становится очевидно, что джойны начинают душить

ну, первое время же другие способы оптимизации будут задействованы

у плохих разрабов да

На самом деле примерно так и есть. В сферическом проекте в вакууме на сферическом сервере если у тебя в табличе около 2 млн. записей и эта таблица интенсивно используется проектом, то возникают неудобства

денормализация это уже от безысходности?)

Цифры +-1.5 млн. в зваисимости от оттюненности сервера и структуры данных

денормализация это уже от безысходности?)

когда и так уже под СУБД отданы лучшие серверы

Если у тебя крутой сервер с 256gb RAM быстрой и SSD дисками, то запас довольно хорош.

если 192, тогда думай о денормализации, да

Да, именно такие числа.

На самом деле примерно так и есть. В сферическом проекте в вакууме на сферическом сервере если у тебя в табличе около 2 млн. записей и эта таблица интенсивно используется проектом, то возникают неудобства

Конечно, вакуум фул блочит))

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

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

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

к примеру, кодят какие-нибудь студенты-индусы)

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

+ денормализация за собой тянет много проблем с консистентностью, поэтому будет только труднее

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

Не могут делать джойн - это SQL в глаза не видели? Такие разработчики могут разве что анусы разрабатывать

а как использовать джоины правильно?

?

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

ну, когда там что-нибудь через 5 табличек идёт, там уже что-нибудь такое страшное может получиться)

некоторые боятся)

Тогда при денормализации не хуже ли будет?

в 5 местах обновлять таблички

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

некоторые боятся)

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

Только не монга

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

второе же?

[потому что если первое - почему тогда никто не использует составные PK ]

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

Прошу прощения, если офтоп, просто ищу направление для розысков

там можно медленные запросы в лог писать

там можно медленные запросы в лог писать

подскажи плиз что смотреть

мне нужно фиксить время запросов (всех)

log_min_duration_statement

log_min_duration_statement = 100

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

т.е. если 0 - то будет писать в лог все ?

да

или включить просто log_duration

поставь 500 и смотри, если пусто - снижай , и так далее

ну и репортик потом pgbadger сделай

Спасибо, коллеги, пошел изучать тему

Да, еще хотел спросить

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

т.е. цель - максимально знать пиковую нагрузку сервера

ты наверное имеешь ввиду пиковую производительность всё же

с конкретным своим приложением

поэтому берется твоё приложение с базой и эмулируется пользовательская нагрузка на приложение

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

"так правильнее" - это всегда следствие от "меньше проблем" и "надежнее", самого по себе понятия не существует

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

Можно и индексы так-то все удалить - только место занимают.

ERROR: S client not available

Да базы данных вообще не нужны! (с) один системный архитектор.

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

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

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

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

Может ускорение вставки без проверок..?

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

вот это единственный вариант, который в голову приходит

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

а целосность как проверять будете? через орм?

а целосность полностью ложится на приложение

Кстати, об орм даже речи не шло на том этапе, когда такое предложили

а целосность полностью ложится на приложение

Да, предложили так

а целосность полностью ложится на приложение

страшновато. Приложение может запросто рухнуть по дороге. Но да - я встречал такие инсталляции

знаю несколько инсталяций таких. Живы. Были факапы, но вроде работают даже.

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

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

это ж MyISAM

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

это ж MyISAM

Честно говоря, мало понимаю. Не специализируюсь

Честно говоря, мало понимаю. Не специализируюсь

раньше в MySQL это был вариант по умолчанию для всех таблиц

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

раньше в MySQL это был вариант по умолчанию для всех таблиц

и вот эти все Joomla'ы/Wordpress'ы по умолчанию именно так и хранили данные

В нулёвом пока проекте на этапе архитектуры такие решения предполагать скорее ок или нафиг?

а вы уверены, что вам нужен sql, а не nosql?

и вот эти все Joomla'ы/Wordpress'ы по умолчанию именно так и хранили данные

а сейчас нет? Тому же вордпрессу конкаренси, вроде, не особенно нужна.

да и целосность тоже

а сейчас InnoDB же по умолчанию?

я не знаю, давно не использовал MySQL/MariaDB

а сейчас InnoDB же по умолчанию?

да

а вы уверены, что вам нужен sql, а не nosql?

У меня такой же вопрос на языке вертелся, но исходили из реляционного подхода к хранению данных

и в innodb до сих пор count делается миллиарды лет

а сейчас InnoDB же по умолчанию?

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

В нулёвом пока проекте на этапе архитектуры такие решения предполагать скорее ок или нафиг?

а это зависит от вашей цели.

и в innodb до сих пор count делается миллиарды лет

а order by rand() limit 1 выбирает в начале вообще всё. ;)