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

[AS0kol]

Хотел бы я увидеть как СУБД будет на полмиллионной таблице искать записи через %like%. Помню, в одной таблице с емкостью несколько сот тысяч строк, в которую забыли добавить индекс, oracle 9 искал поле по id<int> секунд 15.

Главнэ шоб в любом СУБД, то есть интернет магазине работало.

 

[caballero]

Хотел бы я увидеть как СУБД будет на полмиллионной таблице искать записи через %like%.

Так это забота DBA - проставить индексы, настроить оптимальные параметры сервера, задать, если нужно, план запроса и т.д. Нет никаких проблем для промышленной СУБД выполнить поиск по большому количеству записей, для этого они и сделаны. Или ты думаешь рекурсия через WITH быстрее будет?
Впрочем как я уже писал - деревьев с таким количеством записей в реальности не бывает

 

[burning_LEGION]

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

 

[AS0kol]

Так это забота DBA - проставить индексы, настроить оптимальные параметры сервера, задать, если нужно, план запроса и т.д. Нет никаких проблем для промышленной СУБД выполнить поиск по большому количеству записей, для этого они и сделаны. Или ты думаешь рекурсия через WITH быстрее будет?
Впрочем как я уже писал - деревьев с таким количеством записей в реальности не бывает

В интернет магазине есть DBA? Например, у нас в конторе индексы - забота девелоперов, у DBA совсем другие задачи.

Про объемы в реальности (поля ID и PARENTID):


И это на девелоперской схеме, а в production базах объемы на порядки больше.
Ну и хотелось бы посмотреть на чудо-юдо-индекс, который будет использоваться при запросе с like в where.

Вот еще одна табличка:

 

[eugene_kr]

Осилил...

SELECT t1.* FROM shop_productgroups t1 JOIN shop_productgroups t2
ON position(concat('0',t2.group_id) in t1.treeorder) > 0
AND t2.groupname='Процессоры' AND t1.groupname <>'Процессоры'

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

Так это забота DBA - проставить индексы, настроить оптимальные параметры сервера, задать, если нужно, план запроса

Могу объяснить почему указанное решение в приведенном виде нельзя оптимизировать ни индексом, ни планом запроса, ни выдачей памяти оптимизатору для сортировки (это намёк на "оптимальные параметры сервера"). В имеющейся формулировке в тех "случайных" случаях, когда запрос будет работать "правильноожидаемо" , максимум можно выжать из производительности - это одно сканирование индекса по диапазону и одно полное сканирование таблицы. В худшем случае - два полных сканирования таблицы и дисковая сортировка.
Но, если применить теорию, то можно достичь ситуации, когда потребуется только одно индексное сканирование по диапазону и одного взгляда на запрос будет достаточно, что бы понять, какую цель он (запрос) преследует... но это ведь не нужно, так как запрос работает "наугад" и никто не сможет доказать (и принят доказательства) что он (запрос) должен и будет правильно работать.


По теме темы - выкиньте из головы определение функции и доказательство реализуемости (вычислимости) алгоритма. А потом решите задачу из, как тут называют, "практического программирования".


p.s. По поводу полезности теоретических знаний. Случилось мне недавно озадачиться производительностью сервера форума, на котором от 2-5К пользователей онлайн, LA 10-30++ и тормоза. Решение от "практиков" - нужно купить мощный кластер, мигрировать форум и будет "все хорошо". На вопрос "почему?" практики не ответили, сославшись на то, что "хозяин и админ форума - *****и, а много хорошего, мощного и дорогого железа еще никому не мешало, и нужно вообще менять движок форума и "всё переписывать", они же практики...".
А вот решение от "теоретиков" - два десятка строк кода (в штатном механизме настроек сервера форума), два десятка строк конфигов и один "маленький" дополнительный сервер (с мощностью в 1/4 от основного сервера и "быстрыми" винтами для решения текущих проблем с недостатком свободного дискового пространства).
Проверили решение от "теоретиков", оно даже на начальном этапе внедрения оказалось действенным - уровень LA ~ 2 при 2К пользователей онлайн, скорость загрузки страниц форума уменьшилась. При более высокой загрузке сервера страницы будут отдаваться примерно в 10 раз быстрее чем в оригинальной постановке (и ожидается, что будут отдаваться, а не обрывать соединение). Решение от "теоретиков" в сравнении с предложениями от "практиков" оказалось на ~75% дешевле по серверным мощностям, на 90% дешевле по программной составляющей и на 100-% совместимо с существующим ПО (не нужно менять движок форума и переписывать все его оригинальные и не очень оригинальные "плюшки"). А уважаемые "практики" были готовы гарантировать результат от их "решения" только на словах.

 

[caballero]

В интернет магазине есть DBA? Например, у нас в конторе индексы - забота девелоперов, у DBA совсем другие задачи.

речь о сути задачи а не о том как именуется исполнитель

Про объемы в реальности (поля ID и PARENTID):

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

Объяснять в каком случае это не сработает не буду,

и не надо - бредятины тут уже и так понаписывали.

По поводу полезности теоретических знаний.

И зачем было писать что осилил если ни *** не осилил. Речь не о ПОЛЕЗНОСТИ знаний. Любое знание полезно начиная от математики и заканчивая камасутрой. Речь о НЕОБХОДИМОСТИ.

А вот решение от "теоретиков" - два десятка строк кода (в штатном механизме настроек сервера форума), два десятка строк конфигов и один "маленький" дополнительный сервер (с мощностью в 1/4 от основного сервера и "быстрыми" винтами для решения текущих проблем с недостатком свободного дискового пространства).

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

 

[AS0kol]

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

Ну кагбэ сделка (если с английским туго). ID - код сделки, PARENTID - код родительской сделки.

ALTER TABLE DEAL ADD (
  CONSTRAINT FK_DEAL_PARENTID 
  FOREIGN KEY (PARENTID, SITEID) 
  REFERENCES DEAL (ID,SITEID));

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

Так индекс покажешь?

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

 

[Хранитель_]

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

Везде. Почитай педивикию, вникни в суть текста, осознай, что ты не совсем понимаешь о чем говоришь.

 

[caballero]

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

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

Так индекс покажешь?

Индекс чего?

 

[Хранитель_]

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

Главное налепить побольше

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

.

 

[caballero]

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

Осознай что человеку черпающему знания с педивикии лучше не открывать рот лишний раз. Где математка в конкретном случае а не на планете Земля?

Главное налепить побольше готовых решений.

Главное решить задачу. Каким методом никого не **** а заказчика тем более особенно если это будет стоить дешевле. Посоветуй своей маме не использовать готовые решения в виде стиральной машины а стирать руками.

 

[Хранитель_]

Осознай что человеку черпающему знания с педивикии лучше не открывать рот лишний раз. Где математка в конкретном случае а не на планете Земля?

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

А с чего ты взяла, что я черпаю знания с педивикии?

 

[caballero]

Ну я бы тебе предложил полистать "Толковый словарь" Ожегова, но чувствую что ты больше букваря ничего не осилишь

как связано содержание словаря Ожегова с применением математики в програмировании? Наведи порядок в своих мыслях.

 

[AS0kol]

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




Индекс чего?

Читать разучился?
Я же написал, что при пролонгации создается новая сделка (например, надо другую процентную ставку или другие условия поменять. DDL читать тоже не?), а эта новая сделка еще раз может пролонгироваться и так до бесконечности. Более того у этой сделки могут быть порожденные сделки другого типа, которые тоже могут иметь порожденные сделки. Намалюешь две таблицы?

 

[Хранитель_]

Главное решить задачу. Каким методом никого не **** а заказчика тем более особенно если это будет стоить дешевле. Посоветуй своей маме не использовать готовые решения в виде стиральной машины а стирать руками.

Ну да, давай ждать по 10 минут пока загрузиться станица и валюта будет конвертироваться 1:20. Ну это так к примеру.

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

как связано содержание словаря Ожегова с применением математики в програмировании? Наведи порядок в своих мыслях.

Наверное к применению слова "математика" везде и всюду.

 

[caballero]

Ну да, давай ждать по 10 минут пока загрузиться станица и валюта будет конвертироваться 1:20. Ну это так к примеру.

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

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

 

[AS0kol]

Индекс чего?

Для поля, в котором ты предлагешь хранить путь к конкретной вершине графа.

 

[Хранитель_]

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

А я тебе написал, что штиральная машина - готовый не модифицируемый продукт. Он не применяется ни для чего более, чем для стирки белья. Приводи более корректные примеры.

 

[caballero]

Я же написал, что при пролонгации создается новая сделка (например, надо другую процентную ставку или другие условия поменять. DDL читать тоже не?), а эта новая сделка еще раз может пролонгироваться и так до бесконечности. Более того у этой сделки могут быть порожденные сделки другого типа, которые тоже могут иметь порожденные сделки. Намалюешь две таблицы?

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

Для поля, в котором ты предлагешь хранить путь к конкретной вершине графа.

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

А я тебе написал, что штиральная машина - готовый не модифицируемый продукт. Он не применяется ни для чего более, чем для стирки белья. Приводи более корректные примеры.

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

 

[Хранитель_]

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

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