powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Переосмысление роли РБД: очередная хохма
15 сообщений из 15, страница 1 из 1
Переосмысление роли РБД: очередная хохма
    #33166374
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33166452
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где хохма?

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

В этом конкретном случае есть возражения?
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33166475
Выделил ИМХО ключевые слова...
авторФункциональность реляционных баз данных — с их транзакционными, динамическими и многопользовательскими возможностями — значительно богаче потребности в простой сортировке и доступе для однократной записи и в редких случаях прочтения бизнес-информации
...
Не менее важно и то, что перенос больших объемов данных о бизнес-событиях из СУРБД в дополнительное решение на основе неструктурированных файлов приводит к повышению производительности СУРБД в таких задачах, на которые они рассчитаны.
...
Реляционные базы данных — это впечатляющая технология, но это самый дорогостоящий способ хранения больших объемов статической информации, которая нужна лишь на тот случай, если она понадобится когда-нибудь в будущем.
...
Короче говоря, реляционная база данных — слишком большой молоток для гвоздя регистрации цифровых бизнес-событий.
...Мне кааца - все по делу...
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33169728
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
DimonischeГде хохма?

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

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

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

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

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

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

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

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

Другое дело что не следует навешивать на РСУБД несвойственные им задачи, так с этим никто не спорит. Но автор не приводит таких примеров, все ее примеры это как раз задачи для СКЛ серверов. Впечатление такое что она не понимает о чем говорит, по-видимому нужно было написать статью, не очень важно о чем, она это сделала.
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33169745
Sarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Афтар пытается доказать что файл-сервер лучше? Ну может оборудование крутое под сервер и не потребуется. А вот под клиентов... А сетка какая нужна, чтоб он работал быстро и другим не мешал? Имхо, клиент/сервер дешевле будет почти всегда.
автор
Реляционные базы данных настолько въелись в сознание ИТ- и бизнес-профессионалов, что их заведомая пригодность для решения практически любых задач по управлению данными редко ставится под сомнение . Однако пришло время пересмотреть это общепринятое мнение.

Я хотел поставить под сомнение. Но с Коддом спорить не решился
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33169746
Герострат
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
c127 DimonischeГде хохма?

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

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

Во-первых очень плохой перевод. Например правильный "relational database management systems (RDBMS)" превратился в "системы управления реляционными базами данных (СУРБД)" что есть неизвестно что.Вообще-то RDBMS так и переводится -> google.com
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33169755
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
В общем-то я знаю один пример, когда плоская таблица лучше. . Это когда надо переписывать чужую базу, на которую нет документации. Все данные в одной таблице - лепота! Один проход курсором по ней и заполнены все таблицы и все справочники новой базы!
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33169765
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
По статейке. Бред полный. "бизнес-событие".
c127 правильно все забацал.

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

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

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

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


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

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

Скорее всего, когда она еще не была директором, у нее были проблемы c Fox+
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33170122
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Герострат c127
Во-первых очень плохой перевод. Например правильный "relational database management systems (RDBMS)" превратился в "системы управления реляционными базами данных (СУРБД)" что есть неизвестно что.Вообще-то RDBMS так и переводится -> google.com

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

А вообще статья ИМХО не стоит обсуждения. Если проблема есть, то то что предлагает автор проблему все равно не решает, только создает дпополнительные трудности, которые к тому же всем кроме автора статьи хорошо известны.
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33170833
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Когда то вопрос о правильности перевдо RDBMS я задал в dbdebunk.com. От Паскаля пришел ответ, что дескать DB должно управляться соответсвуещей MS. Поэтому R можно отнести и тому и к другому.

Я, кстати, с этим не совсем согласен.
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33170960
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет Всем!

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

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

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

Если я где-то ошибся, прошу меня дополнить.
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33171175
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> неоптимальность хранения больших обьемов данных
> в условиях быстрой генерации вставок и относительно
> редкой выборки;

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

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

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

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

Дополняю: Вы ошиблись в двух тезисах одновременно.
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33172458
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mayton
Если я где-то ошибся, прошу меня дополнить.

В таком случае будет не "дополнить", а "исправить".
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33172806
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
автор
> неоптимальность хранения больших обьемов данных
> в условиях быстрой генерации вставок и относительно
> редкой выборки;

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


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

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

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

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

Человек не ошибся он почти разгадал смысл маркетингового маваши-гири :)
...
Рейтинг: 0 / 0
Переосмысление роли РБД: очередная хохма
    #33174974
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kate Mitchellнеструктурированный файл, перенявший у реляционной базы данных ключевую функцию — индексацию
Г-жа маркетолог Kate Mitchell искренне считает, что ключевой особенностью (а не ключевой функцией, в оригинале –— key feature, перевод действительно дрянной) реляционной базы данных является наличие индекса. Это в полной мере выдает всю «глубину» понимания автором реляционной модели данных и, как следствие, РСУБД. Тут все ясно.
...
Рейтинг: 0 / 0
15 сообщений из 15, страница 1 из 1
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Переосмысление роли РБД: очередная хохма
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]