Математика для программиста.

[AS0kol]

Дерево здесь обсолютно бессмысленно с точки зрения бизнес логики. То что вы так сделали это следствие отсутсвия мозгов.
Дерево должно строится для ОДИНАКОВЫХ сущностей и в том случае где есть необходимость работать с иерархией, что в данном случае бессмысленно. Вы бы еще влепили сюда курс валют, план счетов, филиалы, клиентов их адреса и т.д. Тоже ведь иерархия?


Это СУБД сделает, что я должен показать, команду создания индекса для поля? в любом учебнике по SQL.

Ну, конечно, дауну виднее. Он же не слышал про нормализацию БД. И то, что десятки типов сделок имеют десятки общих полей, кагбэ фигня размером в несколько десятков гигов. И это ж еще не принимая во внимание ситуаций когда надо узнать текущие сделки по клиенту или еще чего.

Ну так где ж твои две таблицы и индекс?

Это СУБД сделает, что я должен показать, команду создания индекса для поля? в любом учебнике по SQL.

Ткни носом в пример создания индекса для поля path, который будет использоваться запросе а-ля:

select value
  from table
 where path like '%custom_path%'

С нетерпением жду.

 

[eugene_kr]

position(concat('0',t2.group_id) in t1.treeorder) > 0

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

 

[caballero]

Ну, конечно, дауну виднее. Он же не слышал про нормализацию БД. И то, что десятки типов сделок имеют десятки общих полей, кагбэ фигня размером в несколько десятков гигов. И это ж еще не принимая во внимание ситуаций когда надо узнать текущие сделки по клиенту или еще чего.

а дерево здесь зачем? в любой сделке есть дата начала и дата конца - какие проблемы получить их для данного клиента. На *** тут иерархия и при чем тут нормализация? И каквая проблема с общими полями? вынеси их в отдельную таблицу и все дела.

Ткни носом в пример создания индекса для поля path, который будет использоваться запросе а-ля:

значит не будет в данном случае. В других будет. LIKE не везде нужен. Какие проблемы.
еще раз - при вменяемом програмировании не может быть дерева больше нескольких сотен (максимум нескольких тысяч) строк и глубины больше десятка уровней. Субд справится и без индекса. А вот с рекурсией по тому что ты нахуевертил как раз справлятся будет проблематично даже с индексами. Никто не строит дерево из договором даже если они ссылаются друг на друга. Когда в твоем воспаленном мозгу будет прояснение попробуй представить как это выглядело бы в реальности на первичной документации.

Ну и? Неужели ZF настолько узкоспециализированный?

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

 

[eugene_kr]

Замечательно - математика где?

Математика была в доказательстве эффективности решения и объяснении текущей практической ситуации.

Насколько я помню, на специальности "прикладная математика" мехмата универа нет предмета "высшая математика". "Высшая математика" была на экономическом факультете у специальности "международные экономические отношения".

 

[caballero]

Математика была в доказательстве эффективности решения и объяснении текущей практической ситуации.

формулы в студию

Насколько я помню, на специальности "прикладная математика" мехмата универа нет предмета "высшая математика". "Высшая математика" была на экономическом факультете у специальности "международные экономические отношения".

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

 

[AS0kol]

а дерево здесь зачем? в любой сделке есть дата начала и дата конца - какие проблемы получить их для данного клиента. На *** тут иерархия и при чем тут нормализация? И каквая проблема с общими полями? вынеси их в отдельную таблицу и все дела.

В случае "отдельних даунских сущностей" ты будешь выборку делать из разных таблиц и склеивать union? А если новый тип сделки добавится, то что?

Ну если ты не догадался, то таблица deal и есть этой общей таблицей. Для полей свойственных конкретному типу сделки есть свои отдельные таблицы. Это и называется нормализацией.
Как же без иерархии проследить историю по депозиту с конретным договором клиента учитывая то, то что он их может открыть несколько штук сразу? Или ты не в состоянии это допереть?

значит не будет в данном случае. В других будет. LIKE не везде нужен. Какие проблемы.
еще раз - при вменяемом програмировании не может быть дерева больше нескольких сотен (максимум нескольких тысяч) строк и глубины больше десятка уровней. Субд справится и без индекса. А вот с рекурсией по тому что ты назуевертил как раз справлятся будет проблематично даже с индексами. Никто не строит дерево из договором даже если они ссылаются друг на друга. Когда в твоем воспаленном мозгу бужет прояснение попробуй представить как это выглядело бы в реальности на первыичной документации.

Ну вот не балаболь, а покажи как же твоя куйня вменяемая реализация будет работать да еще и без индексов или с индексами... Ну и как же с твоим path то работать тогда без использования функций в предикате?
Я тебе примеры показывал из реальной системы, которая работает во многих банках. Так что из нас ****юк пока ты?

 

[caballero]

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

выбрать сделки и отсортировать по дате. Зачем тут иерархия?

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

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

Я тебе примеры показывал из реальной системы, которая работает во многих банках.

Видал я банковские системы писаные доморощеными "программерами". Руки отрывать таким писателяи.

 

[eugene_kr]

position(concat('0',t2.group_id) in t1.treeorder) > 0

Индекс мы увидим?

 

[AS0kol]

выбрать сделки и отсортировать по дате. Зачем тут иерархия?

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

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

Видал я банковские системы писаные доморощеными "программерами". Руки отрывать таким писателяи.

Ну мы уже кагбэ поняли, что твое ***** работает ого-го. Куды

⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.

сиволапым до твоих магазиноф.

И да: публика ждет на презентацию твоего индекса и двух таблиц.

 

[caballero]

Я ж написал, что их может быть несколько сразу по конкретному клиенту

значит несколько и выберет.

да: публика ждет на презентацию твоего индекса и двух таблиц.

какого индекса и каких таблиц? Мне в моем решении никакие индексы не нужны и две таблицы тоже.

 

[AS0kol]

значит несколько и выберет.

Я ж говорил, что мне конкретному депозиту надо, а не по всем.
Таким исполнителям денег не дадут - их накуй пошлют. (насколько я понимаю так и происходит)

какого индекса и каких таблиц? Мне в моем решении никакие индексы не нужны и две таблицы тоже.

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

 

[eugene_kr]

формулы в студию

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

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

Что ожидать от человека, который считает, что "математика" сводится к "формулам" и "школьному курсу"?

 

[caballero]

говорил, что мне конкретному депозиту надо, а не по всем.

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

ксати с моей прошлой работы пара програмеров перешла в банк Альфа (гдето между пушкинской и сумской). Хотели меня перетащить но я вовремя заподозрил неладное. Теперь я в курсе чья невменяемая система там стоит с которой IT отдел не знает что делать - то ли менять то ли переписывать толи мучатся дальше..

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

тогда объясни зачем мне индекс и вторая таблица? Может я в своем решениии чего то не понимаю.

Что ожидать от человека, который считает, что "математика" сводится к "формулам" и "школьному курсу"?

конечно нет - она сводится к питью пива и ебле девок.
Или предьяви использованые в форуме формулы из разделов высшей математики или не ****и.

 

[AS0kol]

Что ожидать от человека, который считает, что "математика" сводится к "формулам" и "школьному курсу"?

Хорошего настроения.

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

Ну кагбэ не факт, что у предыдущего договора тот же самый номер.

ксати с моей прошлой работы пара програмеров перешла в банк Альфа (гдето между пушкинской и сумской). Хотели меня перетащить но я вовремя заподозрил неладное. Теперь я в курсе чья невменяемая система там стоит с которой IT отдел не знает что делать - то ли менять то ли переписывать толи мучатся дальше..

Ну программировать работающее "*****" матами на форуме поспокойнее. Или магазин из шаблона заговнокодить. Тем более что-то мне подсказывает, что ситуация была обратная: ты к ним захотел устроиться, а они такому спецу отказали ввиду его мегаскилов, которые не смог бы оплатить весь банк. Вот и послали куда подальше.

тогда объясни зачем мне индекс и вторая таблица? Может я в своем решениии чего то не понимаю.

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

 

[caballero]

у кагбэ не факт, что предыдущего договора тот же самый номер.

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

 

[eugene_kr]

Куда нам, с нашими многомиллионными хранилищами фактов до твоих проектов...
Почерк у меня неразборчивый, так что формулы можно не смотреть. Речь идёт о моделировании (и оценке влияния предлагаемого решения) очереди запросов, оценке времени их исполнения и ожидания, количество "потерянных" запросов из обработки. Больше деталей - коммерческая тайна.

 

[caballero]

Куда нам, с нашими многомиллионными хранилищами фактов до твоих проектов...

хранилища фактов - это как правило OLAP системмы а не деревья.

Больше деталей - коммерческая тайна.

так всегда ****ят когда надо лапшу на уши навешать. Школота которая утверждает что в их программе охуенное "ноу-хау" появляется на форуме каждые пару дней.
какие на форуме написаном наверняка на PHP очереди запросов? Это тебе что сервер приложений с JMS? И чего вдруг запросы "теряются " в обработке? Типа - а ну его ***** этотт запрос мало ли что там клиент запросил - нажмет рефреш не перетрудится.

 

[AS0kol]

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

Какая же ты тупая зануда. Мне надо сразу из базы вытащить цепочку сделок отталкиваясь от конкретной (может слышал про connect by). При изменении параметров сделки может заключаться новый договор. Хотя это несколько отличается от формы заказа с именем/телефоном заказчика, так что не утруждайся понимаем, а то придаток шеи вспухнет и будет трудно в него есть.

А ведь все начиналось с утверждения, что таких деревьев в реале не существует. И что бы ты не ляпнул, всё бред. Жги еще.

хранилища фактов - это как правило OLAP системмы а не деревья.

А olap в абстрактном облаке живет? Как

⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.

лепет неадеквата.

 

[caballero]

А olap в абстрактном облаке живет?

где оно живет исключительно ***** в контексте данного обсуждения.

Мне надо сразу из базы вытащить цепочку сделок отталкиваясь от конкретной

вот сортируешть по дате и выбираешь от конкретной даты. На *** тут иерархия?

(может слышал про connect by).

слышал. Это команда для работе в Оракле с иерархическими данными. Я это юзал еще в версии 8.0.5 больше 10 лет назад.

Суть моего решения(точнее не моего а того котороен я выбрал) в том что оно может работать в любой БД включающее те у которых нет with или connect by. А смысл - возможность например CMS работать с любой СУБД. Если бы речь шла о непереносимой системме как у тебя то разумеется был бы смысл использовать встроенные средства.

А ведь все начиналось с утверждения, что таких деревьев в реале не существует.

В реале нет. Как результат больного воображения может быть что угодно.
Архитекторы которые это разрабатывали поступили просто. Свалим все в одно дерево - по сути одну таблицу. А ****. Пусть сервер ***рит по рекурсиями на каждый мало мальский запрос -не облезет.
Подобная система в Друпале с его таксономией - тоже все данные разных сущностей сваливаются в одну иерархию. Система известная и даже популярная - но работать с этим занятие исключительно для садо-мазохистов.

 

[eugene_kr]

так всегда ****ят когда надо лапшу на уши навешать

Сразу видно эксперта в методах "****ят когда надо лапшу на уши".
Люди работали, это их труд, как и тех, кто писал библиотеки/инфраструктурные фреймвёрки.

Суть моего решения(точнее не моего а того котороен я выбрал) в том что оно может работать в любой БД включающее те у которых нет with или connect by.

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

select * from table_name

возвращает 50 строк около минуты (в таблице 4 поля - два числа, строка (до 32 символов) и дата). И моих знаний хватает что бы объяснить такое поведение, исправить ситуацию и предотвратить в дальнейшем.
Кстати, где индекс? Или "ноу-хау"?