Новичковые вопросы inside

[su1d]

Новичковые вопросы inside

решил вот на старости лет поработать с "настоящими СУБД"(тм). =)

прочитал почти весь мануал (1.2К страниц в ПДФе -- это ж, геноцид девелоперов и насилие над личностью!), чтобы понять возможности, методы решения разных задач и т.п.
также прочитал SadSpirit'овскую доку "Pg's perfomance".

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

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

а) [..skip..] кипятком с триггеров и хранимых процедур.
но пока ещё не понятно: в чём их главный выигрыш?
- в целостности данных и удобстве работы с ними, когда не нужно "задумываться о мелочах"
- в большей скорости за счёт того, что не проводится дополнительный парсинг запросов (хотя, в триггерах с EXECUTE такого выигрыша нет), и нет передачи данных между клиентом и сервером.

б) не будут ли сильно затормаживать обработку данных куча:
- CONSTRAINT'ов на несколько (на все?) полей сразу
- нескольких триггеров, назначенных на таблицу по разным действиям
- индексов, созданных по expression'сам?

стоит ли вообще все проверки на допустимость значений переносить в БД?

в) какое правило всё-таки взять за основу:
- если какую-то логику можно запихнуть в БД, надо так и делать. даёшь оголтелый pl/PgSQL!
- по возможности всё-таки лучше делать проверки на клиентской стороне
- банальное "каждой задаче -- своё решение", и снова взвешивать каждый подход.

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

д) мне понравился тип text и/или varchar, для которого не нужно задавать пределов длины значения. если в MySQL'е чётко и ясно говорится, что таблицы с рядами фиксированной длины работают быстрее, то что на этот счёт говорит (если вообще говорит) Pg?

e) кто-нибудь использовал массивы в полях? оно тормозит или лучше всё-таки использовать стандартный подход, максимально нормализуя данные?

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

thanks for your time.

 

[Sad Spirit]

Re: Новичковые вопросы inside

Отвечу на что могу.

Автор оригинала: su1d
а) [..skip..] кипятком с триггеров и хранимых процедур.
но пока ещё не понятно: в чём их главный выигрыш?
- в целостности данных и удобстве работы с ними, когда не нужно "задумываться о мелочах"
- в большей скорости за счёт того, что не проводится дополнительный парсинг запросов (хотя, в триггерах с EXECUTE такого выигрыша нет), и нет передачи данных между клиентом и сервером.

я бы скорее поставил на первый пункт. Пример из практики: алгоритмы Nested Sets у меня реализованы именно на PL/PgSQL.

Во втором пункте я бы добавил "и нет лишней обработки данных на клиенте".

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

зависит от того, что именно они будут делать.

- индексов, созданных по expression'сам?

скорее должно ускорить.

стоит ли вообще все проверки на допустимость значений переносить в БД?

стоит, см. ниже

в) какое правило всё-таки взять за основу:
- если какую-то логику можно запихнуть в БД, надо так и делать. даёшь оголтелый pl/PgSQL!
- по возможности всё-таки лучше делать проверки на клиентской стороне

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

г) я не ожидаю от Pg скорости MySQL'я, но за это хочу видеть от него удобство в работе. если я таки выберу стратегию "оголтелого pl/PgSQL", не станет ли всё в конце концов жутчайшим и неприемлемым образом тормозить нагружая сервер?

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

д) мне понравился тип text и/или varchar, для которого не нужно задавать пределов длины значения. если в MySQL'е чётко и ясно говорится, что таблицы с рядами фиксированной длины работают быстрее, то что на этот счёт говорит (если вообще говорит) Pg?

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

 

[su1d]

спасибо!

Пример из практики: алгоритмы Nested Sets

nested sets тормозят.
вчера ночью писал триггер для немножко другого алгоритма: тот же adjacency list с parent_id, только в дополнительной таблице хранятся ссылки на всех родителей -- некий гибрид вложенных множеств и подхода с parent_id.
гонял бенчи -- в MySQL работает значительно быстрее вложенных множеств. графики на http://dev.e-taller.net/dbtree/

и ещё вопрос вызрел:
schemas. нужно ли их использовать? насколько я понимаю, это типа namespaces, которые нужно отводить под каждый проект в отдельности, чтобы они не конфликтовали объектами.

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

З.Ы. что меня вчера убило: PgSQL не держит формата INSERT INTO ... VALUES (...), (...), (...);
это на самом деле так, или я просто в мане потерялся?
пока не отказался от такого формата и не сделал множественную вставку, триггер отказывался работать. =/

 

[Sad Spirit]

Автор оригинала: su1d
nested sets тормозят.

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

и ещё вопрос вызрел:
schemas. нужно ли их использовать? насколько я понимаю, это типа namespaces, которые нужно отводить под каждый проект в отдельности, чтобы они не конфликтовали объектами.

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

З.Ы. что меня вчера убило: PgSQL не держит формата INSERT INTO ... VALUES (...), (...), (...);
это на самом деле так, или я просто в мане потерялся?

Не держит. Чем не устраивает

BEGIN;
INSERT ...
...
INSERT ...
COMMIT;

?

 

[su1d]

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

глянь на графики (последний PNG). новый метод (EXC) берёт от двух старых только достоинства. недостаток один: при очень глубоких деревьях будет большой размер таблицы со структурой. но с другой стороны, размер записи -- всего три int'а.

BEGIN; INSERT; INSERT; COMMIT;

хм, а в триггере разве можно так? щас попробую. спасибо за идею.

во! ещё вопрос: OIDs.
значит ли то, что если я в MySQL'е без них замечательно обходился, теперь я могу со спокойной душой вырубать их в каждой таблице без исключения?
или их можно таки оставлять и использовать как PK после задания ограничения на уникальность?
кажется там что-то говорилось, что в будущих версиях от них вообще могут отказаться...

 

[Sad Spirit]

Автор оригинала: su1d
хм, а в триггере разве можно так? щас попробую. спасибо за идею.

в триггере нельзя, но триггер сам всегда внутри транзакции.

во! ещё вопрос: OIDs.
значит ли то, что если я в MySQL'е без них замечательно обходился, теперь я могу со спокойной душой вырубать их в каждой таблице без исключения?
или их можно таки оставлять и использовать как PK после задания ограничения на уникальность?
кажется там что-то говорилось, что в будущих версиях от них вообще могут отказаться...

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