Обсуждение:Система управления базами данных

Преимущества и недостатки СУБД

Орисс [1] откачен к предыдущей версии.--AlexVinS 19:21, 7 января 2010 (UTC)

Согласен, это вообще нечто странное (мягко говоря) было написано. Евгений Мирошниченко 05:31, 8 января 2010 (UTC)

Документо-ориентированная СУБД

Откатил пока что правку, вычеркнувшую эту модель из списка. В статье приведены примеры СУБД, которые нельзя отнести ни к одной другой модели. Пока этот вопрос не будет решён, настаиваю но оставлении этого пункта, так как он указывает не «в космос», и читатель может сам сориентироваться. Grayed (быв. Pers) 21:49, 29 июня 2011 (UTC)

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

Теперь к обсуждению. Приведите АИ на существование документно-ориентированной модели данных, и вопрос закрыт. Пока таких АИ нет, ваша информация противоречит ВП:ПРОВ. Евгений Мирошниченко 02:43, 30 июня 2011 (UTC)

Вы меня не услышали. Есть класс СУБД, не подпадающих под остальные модели, они перечислены в статье из заголовка темы. Сейчас их обозвали документно-ориентированными. Можете обозвать по-своему, если хотите; лично я потому и предложил обсуждение здесь. Вашу правку я считаю не более правомерной, чем свою, однако начинать ту самую войну правок не собираюсь.

Что касается АИ: «MongoDB (from "humongous") is a scalable, high-performance, open source, document-oriented database», «Apache CouchDB is a document-oriented database...». То есть термин такой есть. Далее, в английской википедии есть неплохая статья en:Document-oriented database (да, я знаю, что это не АИ, но речь не об этом), в ней есть и ссылка на en:Entity-attribute-value model, которая представляет собой то, что у нас названо документ-ориентированной (BTW, и как только это правильно писать, интересно?..) СУБД. Иными словами, имеет место быть путаница, как я полагаю, вызванной внешней корявостью термина «СУБД вида ключ-значение».

Засим на данный момент предлагаю вместо вписывания документ-ориентированных СУБД в список моделей, вписать туда ссылку на (отсутствующую) статью «Ключ-значение», а документ-ориентированные СУБД упомянуть ниже. Так как иначе получается ситуация как в том анекдоте: «...па есть, а слова нет». Grayed (быв. Pers) 03:31, 30 июня 2011 (UTC)

Если и есть СУБД, которые их маркетологи назвают document-oriented, то это ещё не значит, что такая модель данных существует, и тем более это не значит, что эти СУБД следует помещать в классификацию по модели данных. То, кто-то где-то использует термин, мало. В данном случае ситуация как раз полностью обратна процитированному анекдоту, то есть слово-то есть, а предмета, который им обозначается, нет. Все эти доки по данным СУБД я просматривал, их «теоретический уровень» крайне убогий, и вообще писать энциклопедическую статью по документации на продукты — моветон. Это не авторитетные источники.

Статья en:Document-oriented database, которую вы назвали неплохой, я квалифицирую как ужасную и имеющую непримлемо низкий уровень. Начиная с преамбулы: «A document-oriented database is a computer program...» позвольте, с каких это пор база данных называется компьютерной программой? Безграмотность. Далее, определение там идёт не через свойства, а через цель: for document-oriented applications. Это само по себе нонсенс, но давайте тогда подумаем, если я спроектировал обычную реляционную БД для этой цели, т.е. for document-oriented applications, значит она автоматически может называть document-oriented database. Здорово. Дальше в статье никакой теории, никаких определений, только примеры. А примеры не являются определениями и могут даваться только как приложение к теории, но не вместо теории, и тем более не как сама теория. Я удивлён, что такую статью вы назвали неплохой, хуже уже невозможно. Что касается en:Entity-attribute-value model, то она вами названа документ-ориентированной зря, у EAV своя область применения и вовсе не обязательно для document-oriented applications. Складывается такое чувство, что в документ-ориентированные записывают всё подряд, без разбору и чёткого обоснования. Оно и понятно, ведь в данном случае «слово есть, а ...пы как раз нет».

Пока что единственный способ поместить указание на всякую экзотику типа CouchDB, это назвать их "прочие". Евгений Мирошниченко 04:36, 30 июня 2011 (UTC)

«Прочие» — это не классификация, а костыль. Эдак можно млекопитающих разделить на «человекоподобных» и «прочих». Насчёт по модели данных — повторюсь, я с вами уже согласен. Статьи я назвал неплохими по сравнению с русским разделом, у нас нет и этого. Да, документ-ориентированные СУБД — это модный тренд, и это провоцирует изрядный информационный шум, но тем не менее они существуют, и по крайней мере когда один специалист по СУБД говорит другому про документ-ориентированную СУБД, второй его понимает. А это значит, что «слово» таки есть. Grayed (быв. Pers) 11:35, 30 июня 2011 (UTC)

• MongoDB и CouchDB, на мой взгляд, по модели данных иерархические. Надо поискать источники которые со мной согласны.--AlexVinS 08:50, 30 июня 2011 (UTC)

  Не уверен, что эти экзотические СУБД кто-то успел в литературе авторитетно расклассифицировать. Если найдёте, будет интересно. Думаю, тут за неимение лучшего в качестве АИ пойдут даже мимоходные мнения авторитетных специалистов на каких-нибудь форумах. Евгений Мирошниченко 11:17, 30 июня 2011 (UTC)

Предлагаю пока оставить статью СУБД как есть, а заняться доработкой/созданием статей Документо-ориентированные СУБД и Ключ-значение. Кто со мной? Grayed (быв. Pers) 11:37, 30 июня 2011 (UTC)

• Статья Документо-ориентированная СУБД уже есть, её текущее состояние где-то между ВП:КБУ#С1 и ВП:КУ, но вроде запросы стоят, может кто-нибудь что-нибудь и сделает по ней, но если её выставить на ВП:КУ — по формальным признакам удалят в стандартный срок. Мне, как и Евгению, термин документо-ориентированная база данных кажется сомнительным, хотя про документо-ориентированные СУБД (к коим относят MongoDB и CouchDB) сейчас блоггеры и самодеятельные исследователи судачат довольно много. В серьёзных источниках такое сочетание найти не удалось, ну разве что в таком контексте: …MongoDB, which its makers describe as a «document-oriented database» that «bridges the gap between key/value stores and traditional relational databases.» ([2]). Что же касается преамбулы en:Document-oriented database — то это просто языковая беда, характерная (в меньшей степени) и для русского — «базой данных» просто назвали СУБД. Про ключ-значение может как-нибудь напишу статью, поставил себе в to-do…, bezik 14:55, 7 июля 2011 (UTC)

Ссылка на HyTech

Евгений, не совсем согласен с вашей правкой. «Старая» и «малоизвестная» не означает «не значимая». Вы бы в Список СУБД хотя бы её добавили, а то чуть сразу — под нож. К тому же 2009 год (дата последнего обновления официального сайта) я бы старьём по меркам СУБД не называл (не говоря о том, что на её основе работают приложения ФСС). К тому же имеет интересные особенности (в отличие от той же СУБД «ЛИНТЕР»). Про флагманов вообще молчу — это InterBase-то флагман? Grayed (быв. Pers) 13:12, 7 июля 2011 (UTC)

Я согласен с правкой. Более того, данная статья не должна представлять из себя списки СУБД (классифицированные или нет), коих очень и очень много и которых каждый месяц становится всё больше и больше, так что хороший вопрос, что в этой статье делают и ЛИНТЕР, и InterBase. Но вот кого включать, а кого нет и по каким признакам? Наверное, это должен быть очень надёжный и авторитетный и всеобъемлющий обзор всех существующих СУБД. Я такой придумать навскидку не могу… bezik 15:01, 7 июля 2011 (UTC)

Зачем в ряду известных СУБД (в т.ч. флагманов рынка) упоминать старые малоизвестные СУБД? «Интересные особенности», существуют они или нет, к данной теме не относятся. И давайте, ради бога, на сравнивать божий дар с яичницей, я имею в виду, что те же InterBase и даже Линтер известнее НуTech не то что в разы, а на порядки. Линтер достойна упоминания именно в РуВики ещё и потому, что это отечественный продукт (внимание, не просто потому, а ещё и потому). А на какой там экзотике работает ФСС — это, простите за резкость, лишь их собственная головная боль. Евгений Мирошниченко 05:17, 8 июля 2011 (UTC)

Интересные особенности относятся, мы ведь говорим не о создании статьи об этой СУБД, а о ссылке. Данная СУБД, насколько я понял, имеет альтернативный подход к хранению данных относительно тех же MySQL, Firebird и проч., вследствие чего указание на неё эквивалетно указанию на альтернативную точку зрения. А поскольку СУБД таки используется в широких масштабах (пусть в узкой нише, но об RTOS ведь статьи тоже никто не запрещает, не?), то эта точка зрения уже явно не маргинальная. Grayed (быв. Pers) 10:04, 8 июля 2011 (UTC)

Ещё раз повторяю, никакие «интересные особенности», существуют они или нет, не имеют отношения к известности или значимости СУБД. Да и интересность — вещь субъективная. Вам оно интересно, а кому-то другому, может, вовсе нет. Альтернативный подход? Альтернативный чему? Вообще каждая СУБД имеет свою реализацию физического хранения. Что вы поэтому понимаете под «MySQL, Firebird и проч.» для меня решительно загадка. У одной только MySQL несколько вариантов хранения данных. Какие такие «проч.»? Sybase IQ — это «проч.»? А у SyBase IQ вообще радикально иной способ хранения, чем у MySQL или Firebird. По какому признаку вы их всех объединили? Неясно. Да что там за «альтернативный подход», вы читали? Они пишут про использование инвертированных списков, а эта технология древнее мамонтов, да и давно вытеснена b-деревьями. Не смешно. В каких ещё широких масштабах используется HyTech, не уточните? Списка внедрений даже на на их сайте нет, а это само по себе говорит о многом. Евгений Мирошниченко 12:27, 11 июля 2011 (UTC)

Я их не объединял, всего лишь провёл черту: HyTech пошла в чём-то своим путём. Насчёт инвертированных списков — как-то некорректно их сравнивать их с b-деревьями. Что же до вообще подхода — насколько я понял, то, что в других СУБД суть временный журнал транзакций, здесь составляет одну из основных составляющих системы. Сдвиг акцента, достаточно уникальный (по моим скромным сведениям) в среде СУБД, что-то похожее я могу припомнить только в SQLite.

Повторяю, 'все СУБД идут свои путём, это ещё ничего не значит. Насчёт инвертированных списков и с b-деревьев: что тут некорректного? И то и другое используется для ускорения поиска данных, так что сопоставление прямое. Инвертированные списки — решение очень старое, они использовались в середине 20 века, пока по ряду очевидных причин эту технологию в СУБД не вытеснили другие, в т.ч. b-деревья. В наше время рекламировать инвертированные списки для технологий поиска — то же самое, что рекламировать перфокарты для технологии хранения. Евгений Мирошниченко 03:56, 12 июля 2011 (UTC)

А насчёт масштаба — вы почему-то продолжаете отмахиваться от достаточного примера в виде всероссийской (т.е. используемой по всей стране, в тысячах мест) базы ФСС. Аргумент, что там проблемы с поддержкой, отношения опять-таки не имеет. Тогда давайте статьи про все программы, которые сейчас не используются зарежем, там вообще ни о какой поддержке речь не идёт. Ну не имеет отношения наличие техподдержки к значимости! И — важный момент — не забывайте, что мы говорим об уместности ссылки, а не о значимости статьи. Ещё раз: мы обсуждаем не то, насколько уместно создание статьи об HyTech, а насколько уместно её упоминание. Это разные вещи. --Grayed (быв. Pers) 15:20, 11 июля 2011 (UTC)

Уместность? Упоминать HyTech в ряду Oracle и других известных СУБД столь же уместно, как для иллюстрации научных достижений упомянуть заштатную кандидатскую диссертацию какого-нибудь Пупкина наряду с работами Ньютона и Эйнштейна. Что касается ФСС, об этом ниже. Евгений Мирошниченко 03:56, 12 июля 2011 (UTC)

Очень быстрый способ проверки известности какой-то СУБД — посмотреть на список форумов sql.ru. Линтер, кстати, там в заглавных форумах нет, но на форуме представлена богато (261 тем с упоминанием Линтер). А вот тем с упоминаниями HyTech там на порядок меньше да и темы-то какие: Мерзопакость HyTech и JOIN'ы... Замечу, что я лично не имею дела ни с HyTech, ни с Линтер, так что личных интересов и предпочтений у меня нет. Ситуация с развитием HyTech обсуждалась здесь, кстати, там и про ФСС написано:

В двух словах: ФСС использует разработку ОИТ(он же НИСТ(www.nist.ru - сайт закрыт, переезд на openinfotech.ru).

2011 - что-то не срослось...

ФСС не работае сайт тех.поддержки с конца 2010, падение серверов приема отчетности 12.01.2011-14.01.2011.

НИСТ без контракта, но с авторскими провами и тех.документацией.

Новый разработчик от ген.подрядчика без тех.документации и мутная ситуация по поводу авторских прав на разработки НИСТ.

И ни кто не виноват.

Евгений Мирошниченко 05:29, 8 июля 2011 (UTC)

Поисково-мониторинговая система Фонда социального страхования Российской Федерации работает, можете проверить сами. Или вы хотите сказать, что кто-то безгрешен? А главное, какое отношение это имеет ко значимости???

Вы сам о ФСС заговорили, вовсе не я. И кто говорил, что не работает? Читайте цитату повнимательнее. Так говорят, что поддержка умирает. И показано, что этот проект, который вы ставите во главу угла, вообще-то очень не-блестящий, чтобы не него равняться. Не более того. Евгений Мирошниченко 12:27, 11 июля 2011 (UTC)

Евгений, вы опять подменяете понятия: «не блестящий» вообще-то не значит «незначимый». Ещё раз: есть факт использования СУБД в федеральном масштабе. И это однозначно говорит о её значимости. Будете оспаривать? --Grayed (быв. Pers) 15:20, 11 июля 2011 (UTC)

Не покажете то место, где я «подменял» понятия? Если вы не найдёте цитаты, жду извинений. Что касается факта использования СУБД, то кто сказал, что это говорит о её значимости? Подумаешь, какая-то мелкая конторка сумела-таки когда-то пропихнуть свою поделку в одну из федеральных структур. У нас в России так развиты откаты, что и почище случаи встречаются. А чем ещё объяснить давнее решение об использовании HyTech в системе ФСС? Вы знаете, у нас студенты при защите выпускных работ на темы разработки ИС всегда обосновывают свой выбор СУБД. И должен сказать, что даже для выпускной работы обосновать выбор HyTech им было бы невозможно. Смотрим, даже пропуская обсуждение возможностей, просто организационные факторы: СУБД практически неизвестна, опыта массовой промышленной эксплуатации нет, могут быть какие угодно подводные камни. Далее, найти готовые квалифицированные кадры для администрирования неизвестной СУБД невозможно. Далее, фирма-разработчик является мелкой, высока вероятность её краха и прекращения сопровождения СУБД. При этом на рынке есть готовые, опробованные решения, в любых нишах, на любых платформах. Я несколько лет назад принимал участие в проекте обоснования выбора серверных решений (СУБД в т.ч.) для федерального учреждения госгеолконтроля «всего лишь» областного масштаба. И знаю, что это серьёзная работа, при которой анализируется множество факторов, среди которых как опыт применения, так и перспективы поддержки и сопровождения продуктов со стороны производителей являются очень весомыми. Со всей ответственностью заявляю: объяснить выбор продукта подобного HyTech для ИС федеральной службы можно только лоббированием и проплатами.

И это с учётом того, что даже немногочисленные реплики тех, кто слышал о HyTech, пестрят словами «криво, неудобно», «самопал какой-то» (это цитаты).

В это смысле наличие множества success-stories у некоторого продукта есть некая гарантия объективности, а вот единственное значимое внедрение, да ещё с множеством проблем — это лишь подтверждение того, что продукт люди вообще-то выбирать не хотят. Надо сказать, что 1000 мелких инсталляций продукта иногда важнее для его оценки, чем одна непонятно как случившаяся (точнее полностью понятно как случившаяся) инсталляция в госконторе на 1000 мест. Думаю, свежа ещё память с образовательным веб-порталом для Минобразования, сделанным сначала какой-то конторкой за бешенные миллионы государственных денег наспех криво-косо, да ещё и с возможностью перейти с него на порносайты. Евгений Мирошниченко 03:56, 12 июля 2011 (UTC)

Насчёт популярности: о той же МСВС вы вообще форумов не найдёте. В лучшем случае — отдельные темы там и сям. При этом она не только значима, но и используется на многих тысячах компьютеров. Всё-таки не надо путать известность в массах со значимостью. Кто знал о компании HTC до тех пор, пока она не стала производить мобильную технику под собственным брендом? А ведь уже на тот момент она была одним из крупнейших (если не крупнейшим) производителем смартфонов. Но те, кого это касалось, не сидели по форумам, а общались лично, в лучшем случае — на закрытых IRC-каналах. :) СУБД, работающая в масштабах целой страны (даже если плохо работающая, в это я не вникал, и отношения к значимости это, повторюсь, уже не имеет) значима по определению. К тому же HyTech «достойна упоминания именно в РуВики ещё и потому, что это отечественный продукт (внимание, не просто потому, а ещё и потому)». ;) Так что, повторюсь, возвращать правку не буду, но и с вашей формулировкой не согласен. Grayed (быв. Pers) 10:04, 8 июля 2011 (UTC)

А при чём тут хитрые закрытые системы? Для них всё по иному. Мы же обсуждаем массовые продукты, а для них значимость и известность находятся в прямой связи. Кроме того, что там такого особого обсуждать о МСВС, ведь она сделана из Red Hat Linux. Отношение ваших рассуждения об HTC к данной теме вообще мне непонятно. Ну да, любой бренд малоизвестен, пока... хм, не становится широко известным. Это из разряда 2*2=4. И что? При чём тут HyTech? Также я не понимаю, в чём суть способа дискуссии, при котором вы механически копируете мой текст, заменяя «Линтер» на «HyTech». Попробуйте лучше взять раздел «Клиенты и проекты» с сайта Линтер [3] и сопоставить его с каким-то аналогичным разделом с сайта HyTech. Получится у вас это сделать заменой «Линтер» на «HyTech»? Или малость затруднительно? Евгений Мирошниченко 12:27, 11 июля 2011 (UTC)

Отношение примера с HTC самое прямое. Вы фактически утверждаете, что если СУБД не обсуждается на открытых форумах, то о нём и говорить нечего. Я привёл в качестве примера бренд HTC, о котором на открытых форумах так же не говорили, пока HTC сама не прекратила политику чистого OEM именно в качестве контраргумента, потому что по вашей логике тогда HTC тоже не заслуживала бы никакого упоминания (пока не «вышла из тени»). --Grayed (быв. Pers) 15:20, 11 июля 2011 (UTC)

Не надо за меня выдумывать, что я утверждаю, с учётом того, что все мои утверждения написаны выше. Я сказал, цитирую, что «очень быстрый способ проверки известности какой-то СУБД — посмотреть на список форумов sql.ru». Что касается HTC, то ваша попытка перевести обсуждение с продукта на бренд некорректна, это совершенно разные явления. Для корректности приведите пример массового продукта HTC, который был бы с одной стороны широко известен, но при этом об этом продукте ничего не говорилось на специализированных сайтах. Евгений Мирошниченко 03:56, 12 июля 2011 (UTC)

Реально

Добавьте ссылку слева на English-версию данной статьи, а то её нет. 93.185.20.147

Ссылки нет, потому что в en-wiki реально нет статьи про СУБД. Там на всё про всё статья Database. Вход "Database management system" является редиректом на статью Database. Вот такие там идиоты, в en-wiki, так что мы здесь не виноваты. Евгений Мирошниченко 04:40, 14 сентября 2014 (UTC)