Задача

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

Чтобы понять рекурсию, сначала надо понять рекурсию. Возможно, поэтому рекурсивные запросы применяют так редко. Наверняка вы представляете что такое SQL-запрос, я расскажу, чем рекурсивные запросы отличаются от обычных. Тема получилась объемная, приготовьтесь к долгому чтению. В основном речь пойдет об Oracle, но упоминаются и другие СУБД.

Боян. Но я увидел только сегодня и перевел.

http://xkcd.com/327/

SQL Server 2008: обзор нововведений

Microsoft SQL Server – это проприетарная система управления базами данных,
обеспечивающая сетевой многопользовательский доступ,
использует расширенный язык запросов T-SQL.
Ведет свою историю с 1989 года, первоначальная версия создана Sybase.
В предыдущей 2005 версии была введена поддержка CLR, которая позволяла
писать процедуры с использованием языков, работающих на платформе .Net.

Недавно опубликованная на хабре статья Мифы SQL хабаролюдям понравилась. И многие попросили привести примеры почему все работает именно так и не иначе.

Многие разработчики с немалым опытом разработки на любых императивных языках свято верят в то что SQL это тоже самое. Только синтаксис другой. После написания нескольких запросов для вытаскивания данных в свой сервер приложений начинают рождаться мифы о БД.

Задача — есть таблица, нужно создать ее копию… или пустую таблицу с такой же структурой…

Раньше я обычно использовал для этих целей DTS, поскольку потребность в копировании возникала редко и обычно касалась одной таблицы. Меня не ломало запустить Enterprise Manager / Management Studio.

Сегодня возникла необходимость копировать таблицы… много, разные и не выходя за рамки разрабатываемой программульки… т.е. DTS не предлагать, и вообще желательно обойтись только T-SQL'ем.

«ой мамочки, это ж теперь надо получив имя исходной таблицы содрать с нее create statement, не забыть бы про constraints и foreign keys… :( » — подумалось мне.

и тут, о чудо! обнаруживается способ копировать структуру таблицы в одну строку:

select * into [destinationTable] from [sourceTable] where 0 = 1

Если таблица [destinationTable] не существует то она будет создана! С такими же колонками, индексами и прочим. Правда потеряются foreign keys, но танцевать с бубном теперь прийдется гораздо меньше :D

З.Ы.: возможно это боян, но о таком поведении select..into я не знал :")

Наша компания использовала долгое время продукт Imceda — SQL Turbo

Скорость поиска просто поражает. нет аналогов.
В один момент, взяли и закрыли продукт.
Писал в суппорт, никто не знает в чем проблема.
Есть предположения что Майкрософт выкупила технологию и включила в новый Search Engine Server

Просто альтернатив очень мало… и обидно

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

P.S.:
Яндекс сервер не канает (так как есть только бесплатная версия, ищет только по файлам)

Разбираясь с новым Visual C# 2008 (он настолько бесплатный для начинающих разработчиков, что я не удержался), нашел новое для себя слово в науке и технике — GUID.

Привожу пример интересной, как мне кажется, статьи, призывающей использовать глобально-уникальные идентификаторы во всех сферах народного хозяйства. Статья, в основном про .NET и прочий микрософт, но, думаю, будет полезна многим здесь, ибо реализации GUID есть почти во всех современных БД и языках (включая mySQL и PHP ;).

ПС: Если будет интересно, то выложу перевод второй части, где автор отвечает на комменты к первой статье.

Передо мною встала задача — «объединить» несколько типов объектов с разными свойствами в одной таблице для «глобального» поиска. Я перепробовал несколько решений такой задачи. Возможно, вы предложите что-то новое, чего я не смог разглядеть в потенциале SQL.

Рассмотрим задачу более конкретно:

Web 2.0 победоносно шагает по виртуальному миру. Социальные сети растут как грибы после дождя. Теперь в одном месте вы можете хранить свои фото, видеозаписи, писать блоги и слушать музыку. Все это можно комментировать, класть в избранное, копировать… Возможностей много, контент социальных сетей разнородный и разнообразный, и в этом их преимущество.

А теперь представьте себе структуру БД какого нибудь «Вконтакте». Представили? И что вы видите? Множество таблиц с данными? А что еще? Множество таблиц для связей много-ко-многим! Необходимых, с точки зрения реляционной БД, но лишних с точки зрения логики. Но это еще не все. Среди полей таблиц мы видим огромное количество «лишних» полей, являющихся всего лишь внешними ключами, служащими для связей один-ко-много, так же необходимых с точки зрения реляционной теории, но абсолютно бесполезных с точки зрения логики.

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

1. Объединенное хранение

Например, есть таблица типов объектов (ObjectsTypes), таблица самих объектов (Objects) и их свойств (ObjectsFields). По желанию, можно хранить еще и типы полей-свойств, это не принципиально.
Связи между таблицами определены однозначно (объект имеет один тип (typeID) и ряд свойств, связанных с родительским объектом полем objectID), между объектами связь осуществляется и с помощью древовидной структуры (родитель ← ребенок) и путем заведения отдельной таблицы (ObjectsRelations) для сетевой структуры, в которой дочерний элемент может иметь несколько родительских.

2. Индивидуальное хранение

Если представлять эту реализацию на примере, то для хранения блогов нужна таблица Blogs с полями, относящимися к нему, таблица BlogsTopics, хранящая посты и их свойства, таблица BlogsVotes, содержащая все пользовательские голоса и т.д. Можно до бесконечности развивать этот пример — смысл такого хранения в том, что для каждого типа данных создается своя таблица (если нужно, то несколько).

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

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

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

Однако, разработчики СУБД MS SQL предлагают в своей новой версии MS SQL 2008 для реализации древовидной иерархии новый тип хранения данных hierarchyid.

Аналитические функции на примере Oracle, функции LAG.
Прочитав этот материал вы поймете, как работают аналитические функции в Oracle. Я рассмотрю только одну функцию LAG, но принцип действия у них один.

К сожалению, у меня не получилось нормально запостать документ из docs.google.com, так что можно читать оригинал статьи здесь.

Рекурсивны SQL запросы являются одним из способов решения проблемы дерева и других проблем, требующих рекурсивную обработку. Они были добавлены в стандарт SQL 99. До этого они уже существовали в Oracle. Несмотря на то, что стандарт вышел так давно, реализации запоздали. Например, в MS SQL они появились только в 2005-ом сервере.

по поводу утверждения «Везде, где можно, используйте Prepared Statements» в статье Как правильно писать SQL-запросы могу сказать следующее: Производительность хранимых процедур MS SQL Server 2000
В общем, кэширование кода — это не всегда хорошо.