Java + Hibernate + Spring :)

> на создание одной страницы приходится делать под 1000-2000 запросов.

ССЗБ

> ибо зачастую на создание одной страницы приходится делать под 1000-2000 запросов.

Ещё из темы про свою СУБД для меня очевидно, что у тебя серьёзные проблемы с как с умением применять SQL в частности, так и с проектированием БД вообще.

>> на создание одной страницы приходится делать под 1000-2000 запросов.

ССЗБ

это не ССЗБ, это реалии ERP. потому что постгрес не умеет делать по-нормальному древовидные запросы - которые возвращают не просто таблицу, а некоторые ячейки это xml/json/прочее-дерево или хотя бы массив.

потому что есть такое «рабочее место продавца», где выводятся:
1. заявки покупателей (12 сентября ООО ромашка поместило заявку).
2. все строки заявки (внутри заявки например 20 строк по разным деталям).
3. все предложения поставщиков по каждой строке заявки (0..много)
4. все предложения продавца покупателю по каждой строке заявки (0..много), поставщик предложил по $1, продавец предложил $3, на эти два процента и живут.
5. все счета по заявке (0..много), например, покупатель сказал что их 20 позиций он купит 1,3,5 у нас. а потом подумал и сказал что 6,7 тоже.

при этом должна быть возможность фильтрации (ибо полная такая таблица потянет на 300к строк), например «хочу те заявки где я указан у покупателя в качестве менеджера или backup менеджера» или «хочу заявки в таких-то статусах» или «хочу заявки где упоминается такая-то деталь» и прочее и прочее. фильтров дохрена.

> проектированием БД вообще.
есть желание не быть голословным и сказать как мне перепроектировать БД?

Велосипед?
OpenERP

есть желание не быть голословным и

сказать как мне перепроектировать БД?

За Ваши деньги - любые капризы. От 100 евро в час.

гарантии?
в том плане что «если производительность не улучшится в N раз» и тд, то наоборот, платишь ты мне за потраченное мною на тебя время?

> есть желание не быть голословным и сказать как мне перепроектировать БД?

Никакого. Оно закончилось ещё в теме про свою СУБД. Пока ты всерьёз считаешь, всё бизнес-логику надо хранить в процедурах и триггерах, наука бессильна.

> OpenERP
смотрел уже их все, не то это.

> От 100 евро в час.

Артемий Татьяныч, перелогиньтесь

Смотрите не продешевите. Переучивать на порядок труднее чем учить.

> всё бизнес-логику надо хранить в процедурах и триггерах, наука бессильна.

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

гарантии?

мое дело предложить.

если производительность не улучшится в N раз

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

>> От 100 евро в час.

Артемий Татьяныч, перелогиньтесь

да не, нормальная цена для специалиста. правда я что-то сомневаюсь что он специалист и готов реально что-то сделать.

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

ты же слышал, какие у него задачи

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

SELECT * FROM table WHERE 1;

а потом до одури месится в процедуре.

Не нужно. Такое лечится только использованием в проекте какой-нибудь СУБД без намёков на внутреннюю обработку. MySQL 3.*, например. Потом можно переходить к MySQL 5.*, PostgreSQL ну, и наконец, Оракл.

А то человеку с молотком в руках каждая проблема гвоздём кажется.

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

1) Схему, индексы, объемы данных, статистику индексов

Вообще говоря, это вы вероятно уже все посмотрели

2) Запросы, дамп типовой сессии (или статистику запросов)

Это может и не помочь, потому что судя по вашему описанию - проблема как раз в способе/механизме составления запросов

3) к скриншоту хорошо бы требования, потому что просто по нему мало что понятно

Итого - нужен просто кодревью архитектором по вашей технологии.

Лично я php не знаю, ибо дотнетчик

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

Если хочешь серьёзно пообщаться, 27го я буду в москве, стучи в аську/джаббер, приезжай в офис, за полчаса всё покажу. У меня не php а perl.

Просто скриншот может помочь в том плане что будет видно «почему 1000 запросов».

где джойны до 50шт доходят

Вот для таких есть ROLAP/HOLAP

> проблема как раз в способе/механизме составления запросов

проблема в пользователях, которые хотят на каждой странице видеть результаты множества опупительных запросов. Открыл страничку - а там полная статистика за десять лет, детализированный анализ ситуации на рынке и автоматически сгенеренная рекомендация «что же теперь делать». Открыл другую страничку - а там то же самое, только для всех конкурентов, да еще и с детальным сравнительным анализом. Итп.

> r_asian, ты меня с кем-то путаешь?

Тебя с кем-то спутать доволько трудно

я вообще-то оракловый программист

А я вообще-то думал, что оракл - это СУБД(а не ЯП), в которую скриптовый язык на манер перла добавили только из тех соображений, чтобы индусы, не осилившие SQL, не передавали гигабайты в приложение, а гоняли свои бесконечные циклы на стороне сервера. Так сказать: из отчаяния, не заниматься же образованием всех потенциальных использующих.

где джойны до 50шт доходят

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

> А я вообще-то думал, что оракл - это СУБД(а не ЯП)
зря ты так думал. не знаю, кто тебе сказал такую глупость.
опять же, есть желание - могу скинуть парочку примеров - сможешь в один sql-запрос завернуть БЕЗ ora-00600, съем галстук.
Как пример, нужно выдать заявки клиента по тем счетам к которым у него есть доступ.
То есть select * from ttransactions where src_account_id=... or dst_account_id=...
(не будем более подробно останавливаться, не суть)
Есть счета аналитические (дерево, без операций по этим счетам)
и операционные - привязанные к какому-либо аналитическому счету.
например:
КЛТ-11
---КЛТ-11-2
-------КЛТ-11-2 RUR
-------КЛТ-11-2 USD
-------КЛТ-11-2 EUR
---КЛТ-11-3
-------КЛТ-11-3 RUR
-------КЛТ-11-3 USD
-------КЛТ-11-3 EUR
Пользователю ставится в соответствие массив аналитических счетов (он видит в результате все подсчета) и массив операционных счетов.

Я лишь смог сделать
select * from ttransactions
where src_account_id in (функция_выбора_опер_счетов_по_user_id(:user_id)) or dst_account_id in (функция_выбора_опер_счетов_по_user_id(:user_id))

Любой каприз за ваши деньги.

проблема в пользователях, которые хотят на каждой странице видеть результаты множества опупительных запросов. Открыл страничку - а там полная статистика за десять лет, детализированный анализ ситуации на рынке и автоматически сгенеренная рекомендация «что же теперь делать». Открыл другую страничку - а там то же самое, только для всех конкурентов, да еще и с детальным сравнительным анализом. Итп.

Вы так говорите будто это что-то плохое. Любой каприз за ваши деньги. Исполнитель должен был объяснить заказчику чем чреваты такие требования к ПО.

> проблема в пользователях
пробелма вообще-то в программистах. ты можешь два года убеждать пользователя что ему это не нужно и он может быть даже согласится. Но на самом-то деле ему это ДЕЙСТВИТЕЛЬНО нужно. программист не является богом и царём на этой земле, он лишь исполнитель запросов для тех кто реально занимается делами.

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

а если алгоритм выборки данных очень зависит от внутреннего состояния базы данных? вписывать внтутрь sql-запросов скрипты на LUA что ли? =) и помним что БД асинхронная, актуально для долгих по времени запросов.

представляю сколько такие запросы исполняются

Очень Сложные Вычисления в количестве более 9000 на одну единицу смысла - выполняются долго.

Представь, что к продавцу приходит клиент и хочет купить итальянский кирпич в количестве 1шт. Продавец подходит к компьютеру и щелкает кнопочку «показать минимальную стоимость и время выполнения заказа». Результат - всего два числа на экране. Всего два! Но за этими вычислениями лежит абсолютно безумная цепь из миллионов запросов по распределенной сети магазинов, и анализ этой инфы, и синхронизация т.к. всё вриалтайме.

http://www.relsyst.ru/c-e/sales_orders.html
вот это стандартный экран продавца.
красные - счета
зелёные - строки заявки покупателя
жёлтые и серые (серый-обработанный) - предложения от поставщиков
голубое - предложение покупателю


это ещё продукционный минимум.


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

плюсую скриншот! именно то самое.


кстати, там база тестовая или нет? А то щаз зайдет сюда какой-нибудь тролль да попортит там всё...

> функция_выбора_опер_счетов_по_user_id(:user_id)
не нужна, т.к. счета есть конечная величина, скажу даже больше не изменяемая насколько я помню, после чего это становится самым тривиальным запросом

почитай лучше чего-нить чтоли...

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

>> функция_выбора_опер_счетов_по_user_id(:user_id)

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

почитай лучше чего-нить чтоли..

ну ты напиши а я почитаю. потому что каждое написанное тобой слово по отдельности я понял, а вот слитно ещё не научился.

Ну, галстук ты не съешь, ещё ни один, публично обещавший съесть галстук его публично не ел, он тупо несъедобен (Мишико не в счет, он думал, что его никто не видит и он не обещал).

А на представленный в общем виде пример БД я могу дать только в общем виде представленную рекомендацию:

«подумай, возможно стоит дополнить таблицу счетов полем, облегчающим выборку по нему. Причем так, чтобы во классического размена памяти на производительность ты не остался бы в накладе.»

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

у нас система похожая на банковскую.
включая даже комиссии за привод клиентов.
то есть каждый клиент имеет веб-доступ к системе.
он говорит «хочу перевести мильйон денег со счета КЛТ-87-RUR», ему говорится «включая комиссии это будет мильйонписот», из этих писот двадцать записывается как себестоимость операции (формирование платёжного документа в банке), 100 записывается как комиссия КЛТ-80-привёл-КЛТ-87-RUR за то что КЛТ-80 привёл КЛТ-87 в нашу систему, а оставшиеся 380 записываются в ПРИБЫЛЬ-СИСТЕМЫ.
разумеется все эти счета древовоидные и намного сложнее чем я описал.

ну и разумеется всё забавно кто что видит.
и если КЛТ-87 является баааальшим клиентом то у него есть подсчета на разные проекты и под-пользователи которые могут оперировать только подсчетами.
вобщем счетов дохрена и больше

А обязательно пайтон?

Дело в том, что Java+JPA позволяет выбирать реализации ORM не меняя код в 99% случаев. Пару конфигов поправил и все. Есть EclipseLink, TopLink, Hibernate, OpenJPA и т.д. В каждой из них 100500 опций и они умеют генерировать хорошие запросы на диалекте конкретной БД. Главное просто правильно их настроить. Так как код менять не надо, то можно экспериментировать с готовым приложеним за несколько строк меняя ORM реализацию и ее опции.

Я юзаю EclipseLink, не всем доволен, но это не основная работа, а бесплатная помощь, потому не хочется глубоко копать. Работает почти идеально. Причем на 3% от Xeon )))

> «подумай, возможно стоит дополнить таблицу счетов полем, облегчающим выборку по нему. Причем так, чтобы во классического размена памяти на производительность ты не остался бы в накладе.»

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

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

могу даже показать тебе функции возвращающие pipeline таблицы. типа «список комиссий и себестоимостей по данной транзакции» (доходит до 30 штук). дальше это либо инсертится либо делается select sum(amount) from table(Fcomissions_of_transaction()) и используется далее где-то, когда ещё рано реально списывать комиссии.

у меня обычно очень специфичные задачи, включая «ежедневную вгрузку остатков на складах поставщиков» и последующее отображение, есть ли это на складе. и тд.
формирование хитрых транзитных документов (то есть на бумаге детальки сперва покупает гонконг по $1 потом продаёт в россию по $1.99 а россия продаёт уже поставщику по $2). и таких цепочек (разумеется автоматизированно) может быть разное количество и разных типов и длинн.
а когда начинаются вопросы «посчитать прибыль, учитывая откаты» (да, такой вот бизнес) становится особенно смешно. тем более что откаты бывают двух видов - клиент приходит и говорит «выставьте счет по $3 а $1 мне вернёте в конверте», так и «выставьте мне счет на 10000 деталей а выдайте только 8000» (и вот тут начинается писец со складом).

ты уверен что твоя erp сможет это «с минимальным изменением конфигов»?

> То есть ты мне уже предлагаешь денормализацию, 10 минут спустя после того как говорил что я не умею проектировать базы данных?

Не обязательно денормализация. И я разве говорил, что 100% нормализация и есть правильное проектирование БД. Нормализация ведёт к универсализации, а универсализация почти всегда требует жертвоприношений. Но если хорошенько подумать - их можно свести к формальности.

Иногда приходится делать вообще странные на первый взгляд вещи. Обычно это связано с внутренним представлением данных в СУБД. Например ввиду того, что MySQL балуется блокировками, а в MyISAM каждая таблица хранится в отдельном файле, бывает разумно вообще «разрезать» таблицу и делать из неё кучу небольших для каждого значения FOREIGN KEY. Но это, конечно, крайний, клинический случай.

Мой тебе совет - бросай ты это ERP. Я как-то почти занялся этим, но вовремя бросил. Гавнозадачи, гавноинтсрументы, гавноколлектив, гавнозаказчики. Хотя кому как.

а чем заниматься?

> «разрезать» таблицу и делать из неё кучу небольших для каждого значения FOREIGN KEY.

Угу. правда если количество foreign key=100.000 то тогда вообще непонятно что делать.
была тут задачка где табличка была в 100млн записей, но я сказал что
1) нужен postgres
2) я не участвую

> а чем заниматься?

Тут недавно тема была с тестом «сколько стоит час с вами в постели». Очень многие тогда задумались: а тем ли они занимаются.

> 1. заявки покупателей (12 сентября ООО ромашка поместило заявку).

2. все строки заявки (внутри заявки например 20 строк по разным деталям).
...

Простите, это точно ERP, а не CRM?

а линукс - точно серверная ОС, а не десктопная? :)

Ну если так, почему не вспомнили SugarCRM?

> Ну если так, почему не вспомнили SugarCRM?

а при чем тут она, зачем о ней вспомнинать?

Неужели ни OpenERP, ни SugarCRM, ни обе они вместе взятые не удовлетворяют потребностям ТС?

> Неужели ни OpenERP, ни SugarCRM, ни обе они вместе взятые не удовлетворяют потребностям ТС?

Разве что, если ты божественно (на уровне авторов) рабираешься в перепиливании и допиливании Шуги. Правда после перепиливания от Шуги там мало что останется. Так какой смысл ее тогда пилить? Проще сделать свою систему, уже на основе нормальной технологии (Java, .NET), под закрытой лицезией, и продавать ее как централизованный SaaS.

>что MySQL балуется блокировками

На прошлой MMUG оракловцы говорили, что они потихоньку переписывают myISAM и innoDB, чтобы избавиться от кучи блокировок.