Как можно считать СУБД модой?


11

Завершив мой уровень Computing A в 2003 году и получив степень в области вычислительной техники в 2007 году, а также изучив свою профессию в компании с большим использованием SQL, я был воспитан на идее использования реляционных баз данных для хранения.

Таким образом, несмотря на то, что я относительно новичок в разработке, я был ошеломлен, прочитав комментарий (на /software//q/89994/12436 ), в котором говорилось:

[Некоторые разработчики] презирают [SQL] и думают, что это и RDBMS - это увлечение

Очевидно, что компетентный разработчик будет использовать правильный инструмент для правильной работы и не будет создавать реляционную базу данных, когда, например, уместен плоский файл или другое решение для хранения, но RDBM полезны в огромном количестве обстоятельств, так как они могут быть считается причуда?


1
Пожалуйста, предоставьте контекст - где вы прочитали этот комментарий?
Эран Гальперин

8
Все и вся кто-то где-то считает причудами.
Петер Тёрёк

Очень верно, Петер, просто интересно, почему?
StuperUser

5
У таких людей обычно есть другая парадигма, которую они хотят продвигать, что противоречит идее реляционных баз данных. Следовательно, реляционные базы данных плохие и должны уходить. Посмотрите на объектно-ориентированные базы данных, которые еще не достигли критической массы.

Ответы:


28

Ключ находится в R в RDBMS, что означает реляционный. Вопреки распространенному мнению, это означает не отношения между таблицами, а тот факт, что каждая таблица является отношением в математическом смысле слова .

Реляционная модель имеет довольно существенные последствия. Вы должны смоделировать свои данные, чтобы соответствовать отношениям и нормализовать эту модель . Если ваше приложение спроектировано как объектно-ориентированная модель, реляционная модель не подходит. Это широко известно как несоответствие объектно-реляционного импеданса .

Одним из подходов к этому несоответствию являются ORM (сопоставители объектных отношений), которые приобрели большую популярность. Но они не являются верным решением, они больше похожи на решение проблемы. Они до сих пор не решают проблему отображения наследования классов на реляционную модель.

Истинным решением для объектно-реляционного несоответствия являются OODBMS , которые, к сожалению, не получили большого распространения. Популярным движком, изначально поддерживающим OOBD, является PostgreSQL, который является гибридной OO / RDBMS. Другая OODBMS - это Zope Object DB , которая построена на Python и в типичной установке использует RDBMS в качестве базового движка.

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

Ни OODBMS, ни NoSQL не являются «простым файлом».


2
@Daniel: он, конечно, не сказал, что реляционная модель была проблемой, которая требует решения; он сказал именно то, что вы сказали - если вы привержены моделированию своего программного обеспечения на объектно-ориентированной парадигме, тогда реляционная модель является проблемой.
Carson63000

1
@Carson: мои извинения, но я не так прочитал ответ. @vartec говорит: «Истинное решение - это OODBMS (который, к сожалению, не получил большой тяги)». Я с уважением не согласен: я бы сказал, что истинное решение состоит в том, чтобы понять реляционную модель и эффективно использовать ее. OODBMS является плохим решением для случаев, когда вы должны использовать принципы OO для вашей модели данных, что, конечно, не является универсальным случаем.
Даниэль Приден

1
@Daniel: Я думал, что он имел в виду, что OODBMS была истинным решением, опять же, если вы стремитесь смоделировать свое программное обеспечение на объектно-ориентированной парадигме. Дело не в том, что реляционная модель была проблемой сама по себе, а в том, что OODBMS была ее решением. Но в любом случае, не особо обсуждая, кто из нас правильно понял Вартека, я уклонюсь и позволю ему уточнить, если он этого хочет. :-)
Carson63000

1
@Daniel: Контекст является важным. Я четко говорю, что реляционная модель является проблемой в контексте ООП. Теперь, насколько универсален ООП или нет, это выходит за рамки этого ответа. И кстати. OODBMS - это не «решение для бедняков», а ORM.
vartec

1
@vartec: Хорошо, я убираю свое пониженное голосование. (Я не могу удалить его, пока сообщение не будет отредактировано.) Думаю, было бы лучше уточнить, что существуют решения, которые не связаны с ОО. И да, я согласен, что ORM хуже, чем OODBMS.
Даниэль Приден

13

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

Должны ли опытные программисты знать запросы к базе данных?

Я сделал утверждение, что если используется база данных RDBMS, то, несмотря на Linq или ORM, разработчик должен обладать глубокими знаниями SQL.

Это было крайне непопулярное утверждение, которое, по-видимому, объясняется существенными различиями во мнениях о важности SQL и менее респектабельным мнением о том, что СУБД по своей природе уступает базам данных NoSQL, таким как MongoDB.

РЕДАКТИРОВАТЬ: Чтобы добавить к моей претензии, я процитирую пользователя SK-logic:

просто помните, что все это увлечение RDBMS является относительно недавней тенденцией. До этого у нас было большое разнообразие подходов. Вы, очевидно, работаете в молодой компании вместе с разработчиками вашего возраста, и, таким образом, у вас нет шансов познакомиться со старыми и более надежными подходами к хранению данных. К счастью, эта недавняя тенденция уже снижается, и старые добрые способы возвращаются, переименованные в «nosql».


Полностью согласен с вами, что разработчики, работающие с БД, должны понимать SQL, чтобы иметь возможность правильно концептуализировать запрос с точки зрения отношений. Однако, надеюсь, Linq / ORM не оптимизируют запросы к абстракции таким образом, чтобы это влияло на запросы, написанные с учетом хранилища данных.
StuperUser

Единственная причина, по которой кто-то скажет, что «это увлечение RDBMS - относительно недавняя тенденция», - показать, насколько седая у него борода. Сначала я работал над типом корпоративных и бизнес-приложений, которые вы описали в 1995 году - тогда доминировали реляционные базы данных, они доминируют сейчас, они доминируют везде, где я работал за прошедшие 16 лет. Сейчас, очевидно, я не так стар, как некоторые, но когда я говорю «относительно недавно», я не имею в виду «за последние двадцать лет».
Carson63000

Проблема в том, что многие разработчики ошибочно приравнивают СУБД к SQL. SQL - действительно ужасный язык по современным стандартам. Это некорректная и неполная реализация «реляционного» языка (SQL на самом деле не совсем реляционный, и это является частью проблемы), который не сильно развился за последние 30 лет. Многие люди, использующие SQL, едва понимают реляционную модель - все, что они знают, это SQL, и поэтому они предполагают, что реляционная модель является причиной их разочарования.
nvogel

@dportas, Конечно, SQL не идеален, но это было настолько важно для каждой моей работы, что я узнал, насколько легче стало жить, когда я начал мыслить в SQL. Если вы дадите мне реляционную модель и зададите мне вопрос на простом английском языке, то я могу написать вам «ответ» на SQL. Вы говорите, что «все, что они знают, это SQL, и поэтому они предполагают, что реляционная модель является причиной их разочарования», тогда они не достаточно хорошо знают SQL. Почему все должно заботиться о самом низком общем демонинаторе все время, как индийский программист, зарабатывающий менее 10 долларов в час при плохом образовании.
maple_shaft

@maple_shaft, если вы думаете на SQL, то думаете о некоторых вещах, которые очень неправильны в терминах отношений. Следует поощрять разработчиков к пониманию базовых концепций, таких как реляционная модель, вместо того, чтобы сосредоточиться на таких языках, как SQL. Если бы больше людей понимали фундаментальные концепции, то, возможно, SQL уже был бы заменен лучшими вещами.
nvogel

9

причуда :

вещь, которая становится очень популярной за короткое время, а затем забывается примерно с той же скоростью ».

СУРБД существуют уже целую вечность (по крайней мере, в терминах CS), так что кто бы ни сказал, что это означает либо сказать что-то другое, либо не имеет смысла.


2
Я хотел сказать что-то еще, см. Мой ответ ниже.
maple_shaft


3
Вероятно, было бы лучше использовать реальный словарь, а не urbandictionary.
Ааронаут

Ааронот - Как насчет Принстона? «Интерес последовал с преувеличенным рвением». wordnetweb.princeton.edu/perl/…
Шона

3

Альтернатива РСУБД - это не просто файл. Когда я учился в школе, OODBMS была новой вещью, и мой профессор был прав, когда назвал это увлечением. Вы должны взглянуть на различные модели и отметить тенденции. Я видел растущую зависимость от OLAP и был бы готов сделать ставку на новую многомерную систему, которая может обрабатывать данные быстрее, не за горами.


Должен ли «желать быть новым» => «желать ставить новое»?
двоичный беспорядок

О, конечно, использовал плоский файл в качестве примера. Это хорошая ссылка на модели БД.
StuperUser

@Binary Да и отредактировано, чтобы отразить это.
Кристофер Биббс

3

Проблема в том, что многие разработчики ошибочно приравнивают СУБД к SQL. SQL - действительно ужасный язык по современным стандартам. Это ошибочная и неполная реализация «реляционного» языка (SQL на самом деле не совсем реляционный, и это является частью проблемы), который не сильно развился за последние 30 лет. Многие люди, использующие SQL, едва понимают реляционную модель - все, что они знают, это SQL, и поэтому они предполагают, что реляционная модель является причиной их разочарования.


1

Без контекста трудно определить, кто / почему утверждает, что RDBM считаются модными.

В краткосрочном и среднесрочном периоде (5 -10 лет) и я бы подумал еще дольше, что не собирается уходить. RDBM предоставляет эффективный и действенный метод хранения, обработки и поиска реляционных данных, который есть у большинства компаний, будь то клиенты / заказы, пассажиры / билеты и т. Д.

Существуют и другие альтернативы, такие как NoSQL, которые, похоже, растут в популарности с открытым исходным кодом.

Как и OLAP, это действительно (на мой взгляд) специализированные базы данных, разработанные, чтобы позволить бизнесу предоставлять своевременную и полезную статистическую информацию о компании и запускать сценарии «что если» на текущих данных. Конечно, почти во всех случаях эти текущие данные поступали из RDMB, обрабатывались и затем вставлялись в базу данных OLAP.


1

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


1

Простой ответ - нет. СУБД не увлечение. Когда вы читаете что-то на веб-сайте LinqPad, имейте в виду, что их целью является продажа лицензий на их продукт.


Вопрос в том, почему его считают модным, а не рекламной риторикой LinqPad. Стандарт LinqPad бесплатный.
StuperUser

Вопрос пришел от него, читающего рекламную риторику LinqPad. Просто указывая на то, что он должен взять с зерном соли.
Tundey

Нет, это не так, это произошло из комментария maple_shaft на programmers.stackexchange.com/questions/89994/… . Копия LinqPad была взята с щепоткой соли, но мне любопытно, согласны ли разработчики с любым утверждением.
StuperUser

Да, рекламная риторика LinqPad заключалась в том, что написание SQL для запросов к СУБД устарело, а не то, что сами СУБД устарели . Они продают лучший способ использовать СУБД, а не альтернативу им.
Carson63000

@StuperUser и Carson63000: Понятно. Моя ошибка.
Tundey

0

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


0

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

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

Концепция СУБД (и ее основного средства, SQL) представляет собой шаг в технологии, который, как и многие другие, может быть заменен лучшими, вот и все.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.