Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2005, 15:52 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
Где хохма? Сказали что для определенного типа использования данных реляционная база не нужна. В этом конкретном случае есть возражения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2005, 16:08 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
Выделил ИМХО ключевые слова... авторФункциональность реляционных баз данных — с их транзакционными, динамическими и многопользовательскими возможностями — значительно богаче потребности в простой сортировке и доступе для однократной записи и в редких случаях прочтения бизнес-информации ... Не менее важно и то, что перенос больших объемов данных о бизнес-событиях из СУРБД в дополнительное решение на основе неструктурированных файлов приводит к повышению производительности СУРБД в таких задачах, на которые они рассчитаны. ... Реляционные базы данных — это впечатляющая технология, но это самый дорогостоящий способ хранения больших объемов статической информации, которая нужна лишь на тот случай, если она понадобится когда-нибудь в будущем. ... Короче говоря, реляционная база данных — слишком большой молоток для гвоздя регистрации цифровых бизнес-событий. ...Мне кааца - все по делу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2005, 16:14 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
DimonischeГде хохма? Сказали что для определенного типа использования данных реляционная база не нужна. В этом конкретном случае есть возражения? Во-первых очень плохой перевод. Например правильный "relational database management systems (RDBMS)" превратился в "системы управления реляционными базами данных (СУРБД)" что есть неизвестно что. Во-вторых всякая задача имеет тенденцию к усложненнию. В любом проекте ИМХО очень быстро плоских файлов перестанет хватать, хотя я сомневаюсь что можно найти проект для которого даже в самом начале плоский файл будет проще чем РСУБД. В-третьих, а как плоские файлы уменьшают количество хранимых данных? Скорее увеличивают, они же ненормализованные, ибо плоские. А куда девать данные потом, их же нужно хранить, как в примере с телефонным провайдером? Правильно, в РСУБД складывать. Не проще ли их туда положить сразу, что и делается сейчас. Проблемы не видно. В-четвертых сказать "Applying an index to a flat file results in a very accessible repository ..." это примерно то же самое что сказать "вставив шестеренку в телегу мы превратим ее в автомобиль". Куда именно ее вставлять а главное как обойтись одной шестеренкой, то бишь одним индексом? По-моему автор не совсем представляет себе как именно используются индексы и что их может быть несколько. В-пятых тезис о высокой цене СКЛ серверов и высоким требованиям к оборудованию это просто бред. Тут этот вопрос уже многократно обсуждался в приложении к файл-серверам, но автор к сожалению с нашей дискуссией не ознакомилась. Например ФБ бесплатный и требует гораздо меньше ресурсов чем например акцес или фокспро. Пусть попробует построить систему управления плоским файлом, которая будет жрать меньше ресурсов и работать быстрее бесплатного ФБ. Многие пыталсь, но вроде успехов пока нет. И в шестых, зачем изобретать квадратноколесный велосипед в виде плоских файлов для однопользовательских приложений если есть однопользовательские встраиваемые БД, почти СКЛ сервера, например http://terrainformatica.com/sqlitedb/. Другое дело что не следует навешивать на РСУБД несвойственные им задачи, так с этим никто не спорит. Но автор не приводит таких примеров, все ее примеры это как раз задачи для СКЛ серверов. Впечатление такое что она не понимает о чем говорит, по-видимому нужно было написать статью, не очень важно о чем, она это сделала. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2005, 03:50 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
Афтар пытается доказать что файл-сервер лучше? Ну может оборудование крутое под сервер и не потребуется. А вот под клиентов... А сетка какая нужна, чтоб он работал быстро и другим не мешал? Имхо, клиент/сервер дешевле будет почти всегда. автор Реляционные базы данных настолько въелись в сознание ИТ- и бизнес-профессионалов, что их заведомая пригодность для решения практически любых задач по управлению данными редко ставится под сомнение . Однако пришло время пересмотреть это общепринятое мнение. Я хотел поставить под сомнение. Но с Коддом спорить не решился ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2005, 08:39 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
c127 DimonischeГде хохма? Сказали что для определенного типа использования данных реляционная база не нужна. В этом конкретном случае есть возражения? Во-первых очень плохой перевод. Например правильный "relational database management systems (RDBMS)" превратился в "системы управления реляционными базами данных (СУРБД)" что есть неизвестно что.Вообще-то RDBMS так и переводится -> google.com ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2005, 08:39 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
В общем-то я знаю один пример, когда плоская таблица лучше. . Это когда надо переписывать чужую базу, на которую нет документации. Все данные в одной таблице - лепота! Один проход курсором по ней и заполнены все таблицы и все справочники новой базы! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2005, 09:45 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
По статейке. Бред полный. "бизнес-событие". c127 правильно все забацал. Но хочется немного дополнить. Мне думаются, что "ноги" у этой статьи растут из времен 286 компов и dBase III. Когда действительно железо файл-серверов плохо справлялось с обработкой большого количества файлов при их "соединении" последовательным доступом. Снижало производительность и наличие большого количества открытых индексных файлов (*.cdx Фокса - ответ на эту проблему). И уж совсем туго было, если все не вмещалось в оперативной памяти. Был найден выход! Основная таблица разбивалась на несколько маленьких, например, по периоду данных или еще какому признаку. И мы имели "стройную" систему из файлов: 199101ss.dbf 199102ss.dbf 199103ss.dbf И, разумеется, для получения инфы эти файлы были самодостаточны! Никаких отношений с другими таблицами базы! Ведь каждый лишний открытый файл - лишние тормоза! Только вот мне непонятно, почему эти методы до сих пор продолжают применятся. Ведь гигантский скачок в области производительности железа и технологий доступа сняли все эти проблемы. Ключевые слова Об авторе: Кейт Митчелл — генеральный директор компании CopperEye. До этого она работала старшим вице-президентом по маркетингу и развитию бизнеса в фирме SeeBeyond Technology. Скорее всего, когда она еще не была директором, у нее были проблемы c Fox+ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2005, 10:40 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
Герострат c127 Во-первых очень плохой перевод. Например правильный "relational database management systems (RDBMS)" превратился в "системы управления реляционными базами данных (СУРБД)" что есть неизвестно что.Вообще-то RDBMS так и переводится -> google.com В интернете много чего можно найти. RDBMS переводится именно как РСУБД. Существует стандартная терминология, ей лет 30, нужно ее придерживаться. Но это далеко не единственный ляп в переводе. А вообще статья ИМХО не стоит обсуждения. Если проблема есть, то то что предлагает автор проблему все равно не решает, только создает дпополнительные трудности, которые к тому же всем кроме автора статьи хорошо известны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2005, 00:42 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
Когда то вопрос о правильности перевдо RDBMS я задал в dbdebunk.com. От Паскаля пришел ответ, что дескать DB должно управляться соответсвуещей MS. Поэтому R можно отнести и тому и к другому. Я, кстати, с этим не совсем согласен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2005, 11:20 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
Привет Всем! Как я понял, автор хотел сказать что у современных РСУБД есть ряд недостатков. Попробую их перечислить - неоптимальность хранения больших обьемов данных в условиях быстрой генерации вставок и относительно редкой выборки; - избыточная сложность реализации. Если я где-то ошибся, прошу меня дополнить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2005, 12:02 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
> неоптимальность хранения больших обьемов данных > в условиях быстрой генерации вставок и относительно > редкой выборки; В сравнении с чем? > избыточная сложность реализации. В сравнении с чем? > Если я где-то ошибся, прошу меня дополнить. Дополняю: Вы ошиблись в двух тезисах одновременно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2005, 13:06 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
mayton Если я где-то ошибся, прошу меня дополнить. В таком случае будет не "дополнить", а "исправить". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2005, 05:35 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
автор > неоптимальность хранения больших обьемов данных > в условиях быстрой генерации вставок и относительно > редкой выборки; В сравнении с чем? По сравнению с новыми индексными технологиями компании CopperEye. У них супер пупер крутые индексы которые правда пока есть как отдельная опция для Informix. Причем не бинарные и из-за этого они работают очень хорошо. Насколько хорошо надо справшивать у их заказчиков они вроде .... как есть в природе [quot автор] > избыточная сложность реализации. В сравнении с чем? > Если я где-то ошибся, прошу меня дополнить. [quot автор] Человек не ошибся он почти разгадал смысл маркетингового маваши-гири :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2005, 10:58 |
|
||
|
Переосмысление роли РБД: очередная хохма
|
|||
|---|---|---|---|
|
#18+
Kate Mitchellнеструктурированный файл, перенявший у реляционной базы данных ключевую функцию — индексацию Г-жа маркетолог Kate Mitchell искренне считает, что ключевой особенностью (а не ключевой функцией, в оригинале –— key feature, перевод действительно дрянной) реляционной базы данных является наличие индекса. Это в полной мере выдает всю «глубину» понимания автором реляционной модели данных и, как следствие, РСУБД. Тут все ясно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2005, 09:00 |
|
||
|
|

start [/forum/topic.php?fid=35&tid=1553825]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
45ms |
get topic data: |
15ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
| others: | 218ms |
| total: | 383ms |

| 0 / 0 |
