Варианты есть. Особенно если использовать PostgreSQL. Правда, одним только id родителя, конечно не обойтись. Но, если слегка (или не слегка — а как удобнее) денормализовать таблицу, дописать пару сишных функций и добавить на их основе Operator CLASS, можно вполне непринужденно получать любое количество упорядоченных потомков одним индексируемым запросом безо всякой рекурсии. Вобщем-то можно обойтись и без дополнительных функций — использовав преобразование к бинарным строкам — но там возникает несколько засад с экранированиями спецсимволов, посему проще все-таки с функциями. Побочным эффектом денормализации будет необходимость апдейтить потомков при перемещении или копировании узла. Но в любом случае получается значительно экономичнее, чем nested sets, при сохранении максимальных скоростей выборки.
Впрочем, адекватно такую схему можно сделать на PostgreSQL и на Oracle (возможно получится на MS SQL, или еще на чем-нибудь «толстом» — но тут я просто не в теме). То есть, универсальность в широком смысле теряется.
title — наименование (name пришлось заменить на title, потому что name это ключевое слово для PostgreSql)
Использую PostgreSQL с 1999 года.
Поле с названием name встречается в каждой базе данных.
CREATE TABLE mail (
name character varying,
id integer NOT NULL
);
(пример из какого-то актуального бэкапа)
Что я делаю не так?
Вообще говоря — представляю. очень даже.
Там все вообще говоря просто — в блоке (если мы говорим о функции) мы присваиваем переменной некие значения. Например — про то, что следующий блок у нас завершился ошибкой. В следующем блоке мы меняем значение переменной. Как-то примерно так.
Либо, перед окончанием транзакции проверяем (по определенным, напрямую зависящим от транзакции критериям), что именно у нас сработало, а что — нет — (этот способ сравнительно легко гуглится) и обрабатываем результаты.
Но, как я уже писал выше, savepoint в функциях может вызывать (либо вызывает — еще раз вынужден повториться — поскольку сам я эту штуку не тестировал а из найденных обсуждений четкого вывода сделать тоже нельзя — я не знаю, может вызывать, или вызывает) ошибку SPI, посему правильнее и надежнее пользоваться
RAISE EXCEPTION
WHEN RAISE_EXCEPTION THEN
Кстати (подозрвеаю, что вам эта информация известна, а вот кому-то из читателей может помочь) — dblink позволяет открыть постоянное соединение — если соответствующим образом скомпоновать функцию, можно дополнительно увеличить производительность.
Они разные, разумеется. Просто мой подход (он, вообще говоря, как мне кажется годится не только для логирования)))) позволяет обойтись без PERFORM dblink_exec — а я подозреваю, что именно эта штука и тормозит. Причем тормозит за счет perform. Хотя, опять же, я могу и ошибаться.
Собственно — к сути разговора, когда вы пишете про проблемы с производительностью — какого они плана? Насколько оно тормозит? И на каком железе?
Исключительно шкурный интерес — если вы эту штуку тестировали, вы можете серьезно сэкономить мое время))))
Ну, условно говоря, если у вас случилась ошибка вы прыгаете к сохраненному значению, а потом врубаете обработку ошибки (либо сперва вставляете обработку ошибки, а ву случае успешного прохождения этапа эту обработку ошибки удаляете).
Хотя я тут посмотрел — в функциях использование savepoint может вызывать (либо вызывает — тут уже смотреть надо) ошибку. Обходится RAISE EXCEPTION и блоком
EXCEPTION
WHEN RAISE_EXCEPTION THEN…
Вот еще бы про стоимость, скорость и стабильность интернета. Просто для полноты картинки. А то я отчетливо помню, что года три назад в том же Нижнем были определенные проблемы.
Судя по документации, имеются в виду высоконагруженные (в самом полном смысле слова «высоко») проекты типа on-line бронирования, продаж или аукционов. Причем — (опять же суда по моим ощущениям — возможно, когда я документацию перечитаю более внимательно, эти ощущения изменятся) не проекты целиком, но именно их транзакционная часть. То есть что-то вроде поддержки только корзины интернет-магазина из расчета 50 килопокупок в секунду.
По первому впечатлению от документации — мощная штука. Но, не то, чтобы на любителя. В смысле — любитель с ней (IMHO) не справится.
Аппаратные требования — 2 и больше ядер (от 8 для оптимальной производительности)
Память — от 4 Гб
Каждой таблице сопоставляются процедуры, содержащие SQL и дополнительные обсчеты этого SQL. Фактически — каждой таблице соответствует класс Java, отвечающий за все манипуляции с таблицей.
Производительность достигается за счет партиционирования таблиц, отказа от постоянного журналирования и хранения транзакции в ОЗУ.
Крайне специфическое применение (во всяком случае — на текущий момент)
In other words, VoltDB's target audience is what have traditionally been known
as Online Transaction Processing (OLTP) applications
Есть шанс, что через пару-тройку версий их этой штуки может поллуиться нечто более, чем юзабельное (Может быть, уже получилось — но тут надо пробовать.)
Попробовать вычислить их имена из структуры голосований и погуглить, либо подождать, пока их имена, фамилии и должности (или что там у них есть) будут опубликованы на сайте.
Или третий вариант — попробовать задать вопрос организаторам.
Просто это самая большая веб-студия в России. Больше всего народу, самый большой оборот, больше всего проектов. И сами проекты весьма жирные.
Вобщем-то только поэтому и может.
Потому что после объединения с Wunderman они не только портфолио обновлять прекратили, так еще и креатив сайтов у них (на сугубое мое IMHO) рухнул.
Может быть потому, что экспертов не 11, а 50? Другой вопрос, почему на сайте выводятся только 11 экспертов с фотками. Может быть, дело именно в том, что фотки не прислали?
не знаю, насколько это предложение можно назвать экономным вариантом, но, по крайней мере, с качеством связи и шириной канала там проблем нету. Использовала пара знакомых (сам я их каналами связи не пользуюсь, но сервера наши стоят у них в дата-центре и проблем особых никогда не возникало).
Впрочем, адекватно такую схему можно сделать на PostgreSQL и на Oracle (возможно получится на MS SQL, или еще на чем-нибудь «толстом» — но тут я просто не в теме). То есть, универсальность в широком смысле теряется.
Использую PostgreSQL с 1999 года.
Поле с названием name встречается в каждой базе данных.
CREATE TABLE mail (
name character varying,
id integer NOT NULL
);
(пример из какого-то актуального бэкапа)
Что я делаю не так?
Там все вообще говоря просто — в блоке (если мы говорим о функции) мы присваиваем переменной некие значения. Например — про то, что следующий блок у нас завершился ошибкой. В следующем блоке мы меняем значение переменной. Как-то примерно так.
Либо, перед окончанием транзакции проверяем (по определенным, напрямую зависящим от транзакции критериям), что именно у нас сработало, а что — нет — (этот способ сравнительно легко гуглится) и обрабатываем результаты.
Но, как я уже писал выше, savepoint в функциях может вызывать (либо вызывает — еще раз вынужден повториться — поскольку сам я эту штуку не тестировал а из найденных обсуждений четкого вывода сделать тоже нельзя — я не знаю, может вызывать, или вызывает) ошибку SPI, посему правильнее и надежнее пользоваться
RAISE EXCEPTION
WHEN RAISE_EXCEPTION THEN
Кстати (подозрвеаю, что вам эта информация известна, а вот кому-то из читателей может помочь) — dblink позволяет открыть постоянное соединение — если соответствующим образом скомпоновать функцию, можно дополнительно увеличить производительность.
Собственно — к сути разговора, когда вы пишете про проблемы с производительностью — какого они плана? Насколько оно тормозит? И на каком железе?
Исключительно шкурный интерес — если вы эту штуку тестировали, вы можете серьезно сэкономить мое время))))
Хотя я тут посмотрел — в функциях использование savepoint может вызывать (либо вызывает — тут уже смотреть надо) ошибку. Обходится RAISE EXCEPTION и блоком
EXCEPTION
WHEN RAISE_EXCEPTION THEN…
Аппаратные требования — 2 и больше ядер (от 8 для оптимальной производительности)
Память — от 4 Гб
Каждой таблице сопоставляются процедуры, содержащие SQL и дополнительные обсчеты этого SQL. Фактически — каждой таблице соответствует класс Java, отвечающий за все манипуляции с таблицей.
Производительность достигается за счет партиционирования таблиц, отказа от постоянного журналирования и хранения транзакции в ОЗУ.
Крайне специфическое применение (во всяком случае — на текущий момент)
Есть шанс, что через пару-тройку версий их этой штуки может поллуиться нечто более, чем юзабельное (Может быть, уже получилось — но тут надо пробовать.)
Попробовать вычислить их имена из структуры голосований и погуглить, либо подождать, пока их имена, фамилии и должности (или что там у них есть) будут опубликованы на сайте.
Или третий вариант — попробовать задать вопрос организаторам.
Что-нибудь да сработает
Вобщем-то только поэтому и может.
Потому что после объединения с Wunderman они не только портфолио обновлять прекратили, так еще и креатив сайтов у них (на сугубое мое IMHO) рухнул.
Их можно по урлам найти, если очень захочется.