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

А варианты? Цель - быстро работающая база, целевой уровень нагрузок, как у системы вроде QIWI

А варианты? Цель - быстро работающая база, целевой уровень нагрузок, как у системы вроде QIWI

вам надо быстро или надежно?

что такое CAP-теорема - немножко представляете?

троллинга ради, эту теорему никто не доказал

троллинга ради, эту теорему никто не доказал

Линч доказала

конечно никто http://dl.acm.org/citation.cfm?id=564601

линч ?

Что не отменяет нерелевантность CAP-теоремы к обсуждению)

что такое CAP-теорема - немножко представляете?

Прочитал пару абзацев на Википедии. Вы к чему? :)

в этом чяте за фразу — у меня в кластере имеется CP — не банят.

Прочитал пару абзацев на Википедии. Вы к чему? :)

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

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

Простите, но это изменит возможный список аргументов за и против такой оптимизации?

Спасибо за совет, конечно, я подумаю над этим вопросом

Простите, но это изменит возможный список аргументов за и против такой оптимизации?

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

решайте сами, что вам дороже

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

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

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

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

Как же тогда живут те кто использует такой подход?

Как же тогда живут те кто использует такой подход?

понятия не имею. У меня есть два диаметральных опыта использования такой схемы. В первом случае нагрузка смешная (единицы запросов в минуту, сервер просто один). Во втором нагрузка большая (тысячи запросов в секунду), но в nosql хранятся только некритические сырые данные, и потерять 10-15 процентов данных в течении дня никакой проблемы не представляет

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

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

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

Ну вдруг от нее какие то реляционные свойства требуются

Но вопрос законный

Ну вдруг от нее какие то реляционные свойства требуются

а как реляционные свойства без отношений организовать? А отношения - это и есть ключи

Отношения это не констрейнты

Джойнить можно и без fk

легко, spatial relationships - они отношения, но не fk

очень специфичный случай, ИМХО

в общем мы возвращаемся к началу - нужно понять, чего хотят

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

В общем случае

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

данные переводов - это деньги

потеряете транзакцию - вас на органы разберут. И совершенно правильно сделают

Совершенно верно, данные не потерять - очень важно

тогда я не понимаю, в чем вопрос

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

В угоду производительности

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

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

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

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

Или я просто не правильно понимаю?

"внешние ключи в реляционной базе" или "fk в постгресе"?

первое - абстрактная модель, второе - реализация

"внешние ключи в реляционной базе" или "fk в постгресе"?

Вот я как-то сейчас знак равенства поставил, чувствую, что зря

Ну они же связаны

Я про связь инструмента и идеи

Убираем инструмент, оставив идею?

в постгресе есть постгис, в окологисах вместо оператора a = b по fk обычно ходит ST_Intersects(a,b)

джоины есть, отношения есть, fk нет :)

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

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

Если приложение месяцами работает без обновлений и без ошибок значит все консистентно

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

Ахаха, жжете, давно я так не смеялся

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

Девопсы в своем канале какие совсем отбитые. Не ну серьезно

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

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

ключи должны помочь вам избежать этого

Девопсы в своем канале какие совсем отбитые. Не ну серьезно

Поэтому я ушёл оттуда очень быстро.

Девопсы в своем канале какие совсем отбитые. Не ну серьезно

после того, как мне на полном серьезе обьяснили, что JIRA - это CRM - я уже ничему не удивляюсь. Хоть и сам devops

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

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

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

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

Девопсы в своем канале какие совсем отбитые. Не ну серьезно

там какой-то ужас и кошмар. Сиськи, Амо сделана на битриксе, хрыч, иммиграция... жестят, это даже не лор:)

ERROR: S client not available

там какой-то ужас и кошмар. Сиськи, Амо сделана на битриксе, хрыч, иммиграция... жестят, это даже не лор:)

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

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

у нас по пятницам в рабочем чатике сиськи выкладываем ))

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

Оно контрпродуктивно, что ли. Не сиськи. То есть и полезности ноль, и оффтоп сплошной, как будто всех лжепавлик дуров покусал ей-богу.

у нас по пятницам в рабочем чатике сиськи выкладываем ))

Мальчики/девочки - без разницы?:) ps: блин, щас и в этот чат грязь оффтопную на ногах занесём.

Мальчики/девочки - без разницы?:) ps: блин, щас и в этот чат грязь оффтопную на ногах занесём.

У нас одна она. Не возражает ))

Разбавлю: могу я в саасе коммерческом использовать postgrespro без лобызания лицензии?

У нас одна она. Не возражает ))

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

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

Да спать пора.

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

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

Разбавлю: могу я в саасе коммерческом использовать postgrespro без лобызания лицензии?

Формально: нет

Формально: нет

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

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

постгреспро стал платным?

постгреспро стал платным?

сертифицированный всегда был

https://postgrespro.ru/products/postgrespro_cert

а не сертифицированный

хочется прикрутить полнотекстовой поиск к таблице - подскажите на сколько % таблица вырастет (подозреваю что зависимость должна быть линейной)

можно сделать функциональный индекс по ts_vector'ам текстового поля

ДОбрый день! Подскажите, логгировать все запросы в pg – это норма или даст какой-либо оверхед\проблемы?

даст оверхед

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

Да, это и так происходит. Тут вопрос, что вот был запрос, выполнялся быстро-быстро, условно, за x времени. Вдруг начал деградировать. Чтобы отследить эти моменты

можешь за pg_stat_statements следить

Хорошая штука, спасибо

Приветствую товарищи, вопрос банальный, делаю простой интернет магазин плюс еще склад, таблицы нечто подобное: Users(roles), Customers, Items (Item by categories), Orders, Остатки, вопрос такой, может уже есть готовое спроектированная база? Или все делать самому?

Зачем тогда свое делать ?

Возьми готовый целиком

Зачем тогда свое делать ?

Может есть ссылка на github.com или блог/книга?