pkarklinЯ уже достаточно на мой взгляд, обосновал, что не может железяка с процем для десктопов и софверным раидом на двух винтах, купленных на Митинском радиорынке, называться сервером. Вы не догадываетесь, почему? Как Вы думаете, почему HDD того же объема и скорости для SAN стоит на порядок дороже?


Я вам уже сказал что эта железяка без проблемно может держать 200-300 тысяч вставок в секунду
на каком нибудь NoSQL решении. И выборки делать тоже в сто раз быстрее.
Чтобы добится такой скорости на вашей любимой субд вам нужен сервер в сто раз мощнее и в тысячу раз дороже.

pkarklinавторИскренне надеюсь что 99% ресурсов обычная СУБД тратит в этой задачи на блокировки, консистенцию данных, рассылку почты, секьюрити, статистику, а 1% тратит собственно на саму задачу продовок. Тогда по скоростям все впринципе сходится.
Совершенно верно. Поэтому какое-либо сравнение Вашего детища с промышленными СУБД в части быстродействия не имеет смысла.

Это извечный спор между NoSQL и реляционными СУБД.
То что в данный момент выигрывают на рынке реляционные СУБД вовсе не означает что они лишились всех недостатков по сравнению с NoSQL. Вот и все. Разницу в скоростях нужно банально знать и понимать.
Она составляет гдето десять раз, гдето сто а гдето и тысячу.
В задаче где одна табличка и много запросов и вставок в таблицу простых, помойму выводы очевидны. И iCore7 в этой задаче будет с ОГРОМНЫМ запасом.

RENaissanceBazistВы разобрались хоть что делает эта функция ?
Даже и не думал вникать в этот быдлокод.

Квалификация не позволяет ?

RENaissanceСовершенно верно. Этот этап я очень давно прошел.

Тогда для преуспевающих манагеров по продаже пылесосов (в прошлом кодеров), обьясню на пальцах.
Запрос расчепляет некоторые периоды, тоесть строчки в таблице с колонками StartDate EndDate, и вставляет внутрь другие строчки периодов внутрь по определенным правилам. В данном случае это правило довольно простое, есть период1 и есть период2, они както пересекаются и внутренний период должен попасть именно в это пересечение.

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

pkarklinBazist,

Давайте сойдемся на том, что мы с Вами решаем задачи разного плана. Не в любом месте нужна РСУБД. Точно так же не в любом месте подойдет NoSQL.

Ok

Alexander RyndinDimitry Sibiryakovпропущено...

Потому что желающих кушать больше. К надёжности это не имеет практически никакого
отношения. Она определяется запасами прочности при проектировании и подъёму "на порядок"
не поддаётся.
Неверно. Например, винчестеры, устанавливаемые в сервера, имеют гораздо большее MTBF, чем обычные desktop-диски. Отсюда и цена.

Это наверное из разряда приставок Dendy, 20 лет прошло а их MTBF все не заканчивается и не заканчивается, до сих пор на птичьих рынках можно найти вполне живые экспонаты ...
Имхо обычные винты достаточно надежны + зеркалирования и все норм.

denis2710Bazist,
BazistНа каком нибудь шарпе это было бы пятнадцать двадцать строчек кода, а для реляционных запросов это вот такой многоэтажный костыль. Эти данные нельзя гнать на клиент чтобы их там ращеплять в отдельном слое, периодов сотни тысяч.
...
Вестимо реляционные СУБД умеют действительно хорошо только таблицы джойнить в запросах. Чтото посложнее, например манипуляция с периодами, уже не торт..

Вроде как не секрет,что во всех адекватных РСУБД давно появилась,возможность использовать процедуры,функции написанные на к-н языке программирования.
Глядя на приведенную пелену быдлокода.
Встает вопрос: религия запрещает использовать CLR ?

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

Ну купите SAN винт, закончится его судьба продажей через 20 лет в рабочем состоянии на eBay какомуто коллекционеру за 9.99$