Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Переосмысление роли РБД: очередная хохма  [new]
Shtock
Member

Откуда: СПб
Сообщений: 3049
http://zdnet.ru/?ID=481743
14 июл 05, 15:52    [1704772]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Где хохма?

Сказали что для определенного типа использования данных реляционная база не нужна.

В этом конкретном случае есть возражения?
14 июл 05, 16:08    [1704915]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
Мимо пробегал...
Guest
Выделил ИМХО ключевые слова...
автор
Функциональность реляционных баз данных — с их транзакционными, динамическими и многопользовательскими возможностями — значительно богаче потребности в простой сортировке и доступе для однократной записи и в редких случаях прочтения бизнес-информации
...
Не менее важно и то, что перенос больших объемов данных о бизнес-событиях из СУРБД в дополнительное решение на основе неструктурированных файлов приводит к повышению производительности СУРБД в таких задачах, на которые они рассчитаны.
...
Реляционные базы данных — это впечатляющая технология, но это самый дорогостоящий способ хранения больших объемов статической информации, которая нужна лишь на тот случай, если она понадобится когда-нибудь в будущем.
...
Короче говоря, реляционная база данных — слишком большой молоток для гвоздя регистрации цифровых бизнес-событий.

...Мне кааца - все по делу...
14 июл 05, 16:14    [1704956]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
c127
Guest
Dimonische
Где хохма?

Сказали что для определенного типа использования данных реляционная база не нужна.

В этом конкретном случае есть возражения?


Во-первых очень плохой перевод. Например правильный "relational database management systems (RDBMS)" превратился в "системы управления реляционными базами данных (СУРБД)" что есть неизвестно что.

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

В-третьих, а как плоские файлы уменьшают количество хранимых данных? Скорее увеличивают, они же ненормализованные, ибо плоские. А куда девать данные потом, их же нужно хранить, как в примере с телефонным провайдером? Правильно, в РСУБД складывать. Не проще ли их туда положить сразу, что и делается сейчас. Проблемы не видно.

В-четвертых сказать "Applying an index to a flat file results in a very accessible repository ..." это примерно то же самое что сказать "вставив шестеренку в телегу мы превратим ее в автомобиль". Куда именно ее вставлять а главное как обойтись одной шестеренкой, то бишь одним индексом? По-моему автор не совсем представляет себе как именно используются индексы и что их может быть несколько.

В-пятых тезис о высокой цене СКЛ серверов и высоким требованиям к оборудованию это просто бред. Тут этот вопрос уже многократно обсуждался в приложении к файл-серверам, но автор к сожалению с нашей дискуссией не ознакомилась. Например ФБ бесплатный и требует гораздо меньше ресурсов чем например акцес или фокспро. Пусть попробует построить систему управления плоским файлом, которая будет жрать меньше ресурсов и работать быстрее бесплатного ФБ. Многие пыталсь, но вроде успехов пока нет.

И в шестых, зачем изобретать квадратноколесный велосипед в виде плоских файлов для однопользовательских приложений если есть однопользовательские встраиваемые БД, почти СКЛ сервера, например http://terrainformatica.com/sqlitedb/.

Другое дело что не следует навешивать на РСУБД несвойственные им задачи, так с этим никто не спорит. Но автор не приводит таких примеров, все ее примеры это как раз задачи для СКЛ серверов. Впечатление такое что она не понимает о чем говорит, по-видимому нужно было написать статью, не очень важно о чем, она это сделала.
16 июл 05, 03:50    [1710407]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
Sarin
Member

Откуда: Земля, Солнечная система.
Сообщений: 14485
Афтар пытается доказать что файл-сервер лучше? Ну может оборудование крутое под сервер и не потребуется. А вот под клиентов... А сетка какая нужна, чтоб он работал быстро и другим не мешал? Имхо, клиент/сервер дешевле будет почти всегда.
автор

Реляционные базы данных настолько въелись в сознание ИТ- и бизнес-профессионалов, что их заведомая пригодность для решения практически любых задач по управлению данными редко ставится под сомнение. Однако пришло время пересмотреть это общепринятое мнение.

Я хотел поставить под сомнение. Но с Коддом спорить не решился
16 июл 05, 08:39    [1710453]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
Герострат
Guest
c127
Dimonische
Где хохма?

Сказали что для определенного типа использования данных реляционная база не нужна.

В этом конкретном случае есть возражения?


Во-первых очень плохой перевод. Например правильный "relational database management systems (RDBMS)" превратился в "системы управления реляционными базами данных (СУРБД)" что есть неизвестно что.
Вообще-то RDBMS так и переводится -> google.com
16 июл 05, 08:39    [1710454]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
В общем-то я знаю один пример, когда плоская таблица лучше. . Это когда надо переписывать чужую базу, на которую нет документации. Все данные в одной таблице - лепота! Один проход курсором по ней и заполнены все таблицы и все справочники новой базы!
16 июл 05, 09:45    [1710474]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
По статейке. Бред полный. "бизнес-событие".
c127 правильно все забацал.

Но хочется немного дополнить. Мне думаются, что "ноги" у этой статьи растут из времен 286 компов и dBase III. Когда действительно железо файл-серверов плохо справлялось с обработкой большого количества файлов при их "соединении" последовательным доступом. Снижало производительность и наличие большого количества открытых индексных файлов (*.cdx Фокса - ответ на эту проблему). И уж совсем туго было, если все не вмещалось в оперативной памяти. Был найден выход! Основная таблица разбивалась на несколько маленьких, например, по периоду данных или еще какому признаку. И мы имели "стройную" систему из файлов:

199101ss.dbf
199102ss.dbf
199103ss.dbf

И, разумеется, для получения инфы эти файлы были самодостаточны! Никаких отношений с другими таблицами базы! Ведь каждый лишний открытый файл - лишние тормоза!

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


Ключевые слова

Об авторе:
Кейт Митчелл — генеральный директор компании CopperEye. До этого она работала старшим вице-президентом по маркетингу и развитию бизнеса в фирме SeeBeyond Technology.

Скорее всего, когда она еще не была директором, у нее были проблемы c Fox+
16 июл 05, 10:40    [1710488]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
c127
Guest
Герострат
c127

Во-первых очень плохой перевод. Например правильный "relational database management systems (RDBMS)" превратился в "системы управления реляционными базами данных (СУРБД)" что есть неизвестно что.
Вообще-то RDBMS так и переводится -> google.com


В интернете много чего можно найти. RDBMS переводится именно как РСУБД. Существует стандартная терминология, ей лет 30, нужно ее придерживаться. Но это далеко не единственный ляп в переводе.

А вообще статья ИМХО не стоит обсуждения. Если проблема есть, то то что предлагает автор проблему все равно не решает, только создает дпополнительные трудности, которые к тому же всем кроме автора статьи хорошо известны.
17 июл 05, 00:42    [1711168]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Когда то вопрос о правильности перевдо RDBMS я задал в dbdebunk.com. От Паскаля пришел ответ, что дескать DB должно управляться соответсвуещей MS. Поэтому R можно отнести и тому и к другому.

Я, кстати, с этим не совсем согласен.
18 июл 05, 11:20    [1712353]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
mayton
Member

Откуда: loopback
Сообщений: 53016
Привет Всем!

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

- неоптимальность хранения больших обьемов данных
в условиях быстрой генерации вставок и относительно
редкой выборки;

- избыточная сложность реализации.

Если я где-то ошибся, прошу меня дополнить.
18 июл 05, 12:02    [1712534]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
guest_20040621
Guest
> неоптимальность хранения больших обьемов данных
> в условиях быстрой генерации вставок и относительно
> редкой выборки;

В сравнении с чем?

> избыточная сложность реализации.

В сравнении с чем?

> Если я где-то ошибся, прошу меня дополнить.

Дополняю: Вы ошиблись в двух тезисах одновременно.
18 июл 05, 13:06    [1712806]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
c127
Guest
mayton

Если я где-то ошибся, прошу меня дополнить.


В таком случае будет не "дополнить", а "исправить".
19 июл 05, 05:35    [1714600]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
nkulikov
Guest
автор

> неоптимальность хранения больших обьемов данных
> в условиях быстрой генерации вставок и относительно
> редкой выборки;

В сравнении с чем?


По сравнению с новыми индексными технологиями компании CopperEye.
У них супер пупер крутые индексы которые правда пока есть как отдельная опция для Informix. Причем не бинарные и из-за этого они работают очень хорошо. Насколько хорошо надо справшивать у их заказчиков они вроде .... как есть в природе

[quot автор]
> избыточная сложность реализации.

В сравнении с чем?

> Если я где-то ошибся, прошу меня дополнить.
[quot автор]

Человек не ошибся он почти разгадал смысл маркетингового маваши-гири :)
19 июл 05, 10:58    [1715187]     Ответить | Цитировать Сообщить модератору
 Re: Переосмысление роли РБД: очередная хохма  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Kate Mitchell
неструктурированный файл, перенявший у реляционной базы данных ключевую функцию — индексацию

Г-жа маркетолог Kate Mitchell искренне считает, что ключевой особенностью (а не ключевой функцией, в оригинале –— key feature, перевод действительно дрянной) реляционной базы данных является наличие индекса. Это в полной мере выдает всю «глубину» понимания автором реляционной модели данных и, как следствие, РСУБД. Тут все ясно.
20 июл 05, 09:00    [1718726]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить