Когда Вы не должны использовать реляционную базу данных? [закрытый]
Здесь я внес эти изменения, основываясь на предоставленных вами данных.
IF OBJECT_ID('tempdb..#Temp') IS NOT NULL drop table #Temp
CREATE TABLE #Temp
(Name varchar (50) , LastStatus varchar (max) , IBOAccount varchar (10) , Email varchar (max))
GO
INSERT INTO #Temp
Select 'Report A','Email sent to Email1@email.com','47213','Email1@email.com' UNION ALL
Select 'Report A','Email sent to Email100@email.com','13983','Email100@email.com' UNION ALL
Select 'Report A','Email sent to Email101@email.com','437707','Email101@email.com' UNION ALL
Select 'Report B','Email sent to Email103@email.com','NULL','Email103@email.com' UNION ALL
Select 'Report C','Email sent to Email110@email.com','NULL','Email110@email.com' UNION ALL
Select 'Report C','Email sent to Email128@email.com','NULL','Email128@email.com' UNION ALL
Select 'Report C','Email sent to Email2@email.com;Email3@email.com','170891','Email2@email.com;Email3@email.com' UNION ALL
Select 'Report D','Done: 1 processed of 1 total; 0 errors.','NULL','Email200@email.com;Email5000@email.com;Email1000@email.com;Email_001@email.com'
GO;
declare @result table (Name nvarchar(max), email varchar(MAX) )
while (select count(*) from #Temp)>0
begin
declare @email varchar(max) = (select top 1 email from #temp)
declare @Name varchar(max) = (select top 1 Name from #Temp)
delete top (1) from #Temp where Name = @Name;
IF RIGHT(@email, 1) <> ';'
SELECT @email = @email + ';'
DECLARE @Pos BIGINT,
@OldPos BIGINT
SELECT @Pos = 1,
@OldPos = 1
WHILE @Pos < LEN(@email)
BEGIN
SELECT @Pos = CHARINDEX(';', @email, @OldPos)
INSERT INTO @result (name , email)
SELECT @Name, LTRIM(RTRIM(SUBSTRING(@email, @OldPos, @Pos - @OldPos))) email
SELECT @OldPos = @Pos + 1
END
end
select * from @result
Результат:
Name email
Report A Email1@email.com
Report A Email100@email.com
Report A Email101@email.com
Report B Email103@email.com
Report C Email110@email.com
Report C Email128@email.com
Report C Email2@email.com
Report C Email3@email.com
Report D Email200@email.com
Report D Email5000@email.com
Report D Email1000@email.com
Report D Email_001@email.com
7 ответов
По моему опыту, Вы не должны использовать реляционную базу данных, когда любой из этих критериев верен:
- Ваши данные структурированы как иерархия или график (сеть) произвольной глубины,
- , типичная схема доступа подчеркивает перечитывание по записи, или
- there’s никакое требование для специальных запросов.
Глубокие иерархии и графики не переводят хорошо в реляционные таблицы. Даже с помощью собственных расширений как Oracle CONNECT BY, упорно ища деревья могущественная боль с помощью SQL.
Реляционные базы данных добавляют много издержек для простого доступа для чтения. Целостность транзакций и ссылочная целостность мощны, но излишество для некоторых приложений. Таким образом для чтения главным образом приложения, метафора файла достаточно хороша.
Наконец, Вам просто don’t нужна реляционная база данных с ее полноценным языком запросов, при отсутствии неожиданных ожидаемых запросов. Если нет никаких исков, задавая вопросы как, "в скольких 5%-discounted синих виджетах мы продавали на восточном побережье, сгруппированном продавцом?", и никогда не будет, тогда, сэр, можно жить свободные от DB.
Я предлагаю, чтобы Вы посетили Высокий блог Масштабируемости, который обсуждает эту тему почти ежедневно и имеет много статей о проектах, которые выбрали распределенные хеши, и т.д. по RDMBS.
быстрое (но очень неполный ответ) - то, что не все данные переводят хорошо в таблицы эффективными способами. Например, если Ваши данные являются по существу одним большим словарем, существуют, вероятно, намного более быстрые альтернативы что простой RDBMS. Однако это главным образом вопрос производительности, и если производительность не является огромным беспокойством в проекте, и устойчивостью, непротиворечивостью и надежностью, например, то я не вижу много точки в копании в этих технологиях, когда RDBMS является намного более зрелой и хорошо разработанной схемой с поддержкой на всех языках и платформах и огромном наборе решений выбрать из.
Пятнадцать лет назад я работал над системой кредитного риска (в основном большая система обхода дерева). Мы использовали Sybase на HPUX & solaris и performnce уничтожали нас. Мы наняли в консультантах непосредственно от Sybase, которые сказали, что он не мог быть сделан. Тогда мы переключились на базу данных OO (Объектно-ориентированная память в этом случае) и добрались о 100x увеличение производительности (и код был о 100x легче записать также)
, Но такие ситуации довольно редки - реляционная база данных является хорошим предпочтительным вариантом.
Парадигма реляционной базы данных делает некоторые предположения об использовании данных.
- отношение А состоит из незаказанного набора строк.
- Все строки в отношении имеют тот же набор столбцов.
- Каждый столбец имеет фиксированное имя и тип данных и семантическое значение на всех строках.
- строки в отношении определяются уникальными значениями в столбце (столбцах) первичного ключа.
- и т.д.
Эти предположения поддерживают простоту и структуру, за счет некоторой гибкости. Не все задачи управления данными вписываются в этот вид структуры. Объекты со сложными атрибутами или переменными атрибутами не делают, например. При необходимости в гибкости в областях, где решение для реляционной базы данных не поддерживает ее, необходимо использовать другой вид решения.
существуют другие решения для руководящих данных с различными требованиями. Технология Семантической паутины, например, позволяет каждому объекту определять свои собственные атрибуты и самоописывать путем обработки метаданных как атрибутов точно так же, как данные. Это более гибко, чем структура, наложенная реляционной базой данных, но та гибкость идет с собственной стоимостью.
В целом, необходимо использовать правильный инструмент для каждого задания.
См. также мой другой ответ на" базы данных Следующего поколения . "
Когда Вы, схема варьируется много, Вам придется нелегко с реляционными базами данных. Это - то, где базы данных XML или базы данных пары "ключ-значение" работают лучше всего. или Вы могли использовать IBM DB2 и иметь и реляционные данные и данные XML, управляемые механизмом единой базы данных.
Приблизительно 7-8 лет назад я работал на веб-сайте, который стал еще популярнее вне наших начальных ожиданий, и это получило нас в мудрой производительностью проблеме. Так как мы были все относительно неопытны в веб-проектах, это изложило значительную деформацию на нас о том, что сделать вне обычного разделения базы данных на отдельный сервер, выравнивания нагрузки и т.д.
Однажды, я думал о чем-то довольно простом. Так как сайт был основан на пользователях, их профили были сохранены в таблице базы данных обычным путем, кто-то сделает это - идентификатор пользователя, много информационных переменных и наполнит как этот - который обнаружился бы как, пользователи представляют страницу, которую могли искать другие пользователи. Я сбросил все эти данные в простой файл HTML, уже подготовленный как, пользователи представляют страницу и получили значительное повышение - в основном кэш. Я даже сделал систему, что, когда пользователь отредактировал их информацию о профиле, она проанализирует исходный файл HTML, поднимет его для редактирования и затем спугнет HTML назад к файловой системе - получил еще больше повышения.
я сделал что-то похожим с пользователями сообщений отправленный друг другу. В основном везде, где я мог заставить систему обойти базу данных в целом, избежав ВСТАВКИ или ОБНОВЛЕНИЯ, я получил значительное повышение. Это может походить на здравый смысл, но это был поучительный момент. Это не предотвращение реляционной установки по сути, но это - предотвращение базы данных в целом - KISS.
Существует три основных модели данных (CJDate, EFCodd), и я добавляю к ним плоский файл:
- плоский файл (ы) (структура варьируется - от «глупого» простого текста до файлов, соответствующих грамматикам, которые в сочетании с умными инструментами делают очень умные вещи, думают о компиляторах и о том, что они могут делать, узкое применение в моделировании новых вещей)
- иерархические (деревья, вложенные наборы - примеры: xml и другие языки разметки, реестр, организационные диаграммы, и т. д., можно смоделировать все, что угодно, но правила целостности нелегко выразить, а извлечение трудно оптимизировать автоматически, некоторые операции извлекаются быстро, а некоторые очень медленно)
- сеть (сети, графики - примеры: навигационные базы данных, гиперссылки, семантическая сеть, опять же почти все, что можно смоделировать, но автоматическая оптимизация поиска является проблемой)
- реляционная (логика предикатов первого порядка - пример: реляционные базы данных, автоматическая оптимизация поиска)
И иерархические, и сетевые можно представить в относительном выражении onal и relational могут быть выражены в двух других.
Причина, по которой реляционные данные считаются «лучше», заключается в декларативном характере и стандартизации не только языка поиска данных, но и языка определения данных, включая строгую декларативную целостность данных, поддерживаемую стабильным , масштабируемая, многопользовательская система управления.
Выгоды связаны с затратами, которые большинство проектов считают хорошим соотношением для систем (мультиприложений), которые хранят долгосрочные данные, и которые можно будет использовать в обозримом будущем.
Если вы создаете не систему, а отдельное приложение, возможно, для одного пользователя, и вы достаточно уверены, что в ближайшее время вам не понадобится несколько приложений, использующих ваши данные, или несколько пользователей, тогда вы, вероятно, найти более быстрые подходы.
Также, если вы не знаете, какие данные вы хотите хранить и как их моделировать, тогда на это тратятся сильные стороны реляционной модели.
Или если вы просто не заботитесь о целостности ваших данных (что может быть нормально).
Все структуры данных оптимизированы для определенного вида использования, только реляционные, если правильно смоделированы, пытаются представить «реальность» семантически непредвзятым образом. Люди, у которых был плохой опыт работы с реляционными базами данных, обычно не осознают, что их опыт был бы намного хуже с другими типами моделей данных. Возможны ужасные реализации, и особенно с реляционными базами данных, где относительно легко построить сложные модели, вы можете оказаться в руках настоящего монстра. Тем не менее, я всегда чувствую себя лучше, когда пытаюсь представить того же монстра в xml.
Одним из примеров того, насколько хороша реляционная модель, IMO, является соотношение сложности и краткости вопросов, которые вы обнаружите, связанных с SQL.