Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 13   вперед  Ctrl
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54818

mayton
твоя система

Моя система?..

Posted via ActualForum NNTP Server 1.4

31 авг 11, 19:20    [11208742]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
mayton
Member

Откуда: loopback
Сообщений: 53029
Dimitry Sibiryakov
mayton
твоя система

Моя система?..

Извини. Просто ты так рьяно кинулся отстаивать...

Или всё таки твоя?
31 авг 11, 19:28    [11208773]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Shlippenbaranus
Member

Откуда:
Сообщений: 241
FinSoft
интересующаяся_мнением
скип...

Я бы предложил немного отвлечься от обсуждения технических подробностей решения и задуматься, а какой смысл сейчас делать подобную архитектуру? Что мы имеем на сегодня. Сильно выросшую производительность компьютеров. Причем продолжает расти с каждым годом. Многопроцессорные системы пришли уже в быт. Ограничения с размера оперативной памяти сняты в 64-разрядных ОС. И все это дешевеет и дешевеет. Уже можно взять ящик за 50 тыр и организовать на нем одновременную работу много больше 30 пользователей. А в качестве станций ставить всякую рухлядь, специальные долгоживущие и эргономичные терминальные станции, или даже переносные устройства. При этом вся переферия будет работать без всякого обслуживания и с любой точки шарика. Один сервер и приложение со встроенной необслуживаемой базой данных. А тут предлагается не только ставить специализированный софт на 30 компов, но еще и копию данных на каждом создавать.


Знали бы Вы, на чем до сих пор работают не только end-юзеры, но даже разработчики ПО. На прошлой работе, всего год назад, у меня на работе была машина на селероне с ядром Willamette, 128 KB кеша, образца 2002-го года. Вы даже слов, наверное таких не слыхали (между тем, хуже pentium 3). На которой ПО, которое я разрабатывал, поднималось минутами. И сколько сил нужно было потратить на то, чтобы мне заменили ее на что-то условно-двухядерное. После чего у меня образовалась едва ли не лучшая машина в отделе. И ведь это был один из ведущих разработчиков CRM-систем в моей стране.
31 авг 11, 19:38    [11208820]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Shlippenbaranus
Member

Откуда:
Сообщений: 241
mayton
Или всё таки твоя?


Блин, ну что за люди!
31 авг 11, 19:40    [11208829]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Vladimir Baskakov
Member

Откуда:
Сообщений: 2006
интересующаяся_мнением
Vladimir Baskakov
Мелькнула мысль про агрегаты. На машине 1 изменение, затрагивающее агрегаты A1, A2, A3... на машине 2 - А2 А3 A4... и так далее... Когда, и кто пересчитывает эти агрегаты - при постинге изменений? Как они рассылаются? Как выясняется, что их прочли ВСЕ КОМУ ОНИ НУЖНЫ, а не только суперглавный сервер?

Все агрегаты пересчитывает только сервер. На самом деле примерно так происходит: клиент чего-то наменял, отправил это пакетом на сервере. Сервер почитал все полученное, досчитал все, что можно досчитать только централизованно, записал все что получилось (включая агрегаты и то что прислал клиент) в базу с новым номером транзакции, а потом уже всю эту байду кинул бродкастом всем остальным. Т.о. все всегда имеют агрегаты, соответствующие фактическим данным.

Когда пересчитывает? откуда он знает, что и когда надо (пора) пересчитывать? в традиционных БД - когда сработал триггер... условно. Или - запрос послан не базе, а умному серверу приложений. Принять товар! вписали товар в базу, поправили агрегаты. И этот сервер приложений знает, как на запрос отвечать. И крутится он на машине с мощным железом - сервере... Иногда для таких целей удобно использовать язык хранимых процедур БД.

а как это работает, когда сервером может быть кто угодно? - его нужно засунуть в состав толстого клиента.... в общем - наблюдается сращивание собственно движка данных с прикладным ПО...
31 авг 11, 19:49    [11208864]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
FinSoft
Member

Откуда:
Сообщений: 66
Shlippenbaranus
FinSoft
пропущено...

Я бы предложил немного отвлечься от обсуждения технических подробностей решения и задуматься, а какой смысл сейчас делать подобную архитектуру? Что мы имеем на сегодня. Сильно выросшую производительность компьютеров. Причем продолжает расти с каждым годом. Многопроцессорные системы пришли уже в быт. Ограничения с размера оперативной памяти сняты в 64-разрядных ОС. И все это дешевеет и дешевеет. Уже можно взять ящик за 50 тыр и организовать на нем одновременную работу много больше 30 пользователей. А в качестве станций ставить всякую рухлядь, специальные долгоживущие и эргономичные терминальные станции, или даже переносные устройства. При этом вся переферия будет работать без всякого обслуживания и с любой точки шарика. Один сервер и приложение со встроенной необслуживаемой базой данных. А тут предлагается не только ставить специализированный софт на 30 компов, но еще и копию данных на каждом создавать.


Знали бы Вы, на чем до сих пор работают не только end-юзеры, но даже разработчики ПО. На прошлой работе, всего год назад, у меня на работе была машина на селероне с ядром Willamette, 128 KB кеша, образца 2002-го года. Вы даже слов, наверное таких не слыхали (между тем, хуже pentium 3). На которой ПО, которое я разрабатывал, поднималось минутами. И сколько сил нужно было потратить на то, чтобы мне заменили ее на что-то условно-двухядерное. После чего у меня образовалась едва ли не лучшая машина в отделе. И ведь это был один из ведущих разработчиков CRM-систем в моей стране.

Работал я на подобных, только атлонах. До 2004 г, потом взял себе Атлон Barton 2500+ с 512 мб ОЗУ. На нем разработка софта до сих пор, хотя письмо сейчас пишу с тошибовского ноута на 4-ядерном i5 и 4 гигах ОЗУ. А еще у меня сегодня скорость инета 2ГБ, с завтрешнего дня 8ГБ и на 100 рублей дешевле. Если для сервера на 30 пользователей жалко потратить 50 тыр, можно потратить 15-20 тыр - тоже будет за глаза... И это гораздо дешевле, чем платить за обслуживание 30 отдельных компов, тратить время, деньги и нервы на их ремонт и т.п. Ну, сами понимаете...
31 авг 11, 19:52    [11208871]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54818

mayton
Просто ты так рьяно кинулся отстаивать...

А вон там, повыше, рьяно громил.

Но давайте будем объективны: система авторов действительно имеет определённые достоинства.
Она действительно практически неуничтожима, а вышеописанные катастрофические сценарии
обходятся парой административно-технических решений. Например, выделяется 2-3-10
компьютеров, которые никогда не выключаются и выбор нового сервера идёт исключительно из них.

Строго говоря, их система работает как классический MySQL LB-cluster, доведённый до
абсурда: каждому клиенту свой сервер. Соответственно, она имеет все достоинства и
недостатки этого кластера. И может работать в тех же задачах - высоконагруженные
информационные системы в которых чтение намного, НАМНОГО превышает запись. (Хотя, конечно,
быстродействие их выборок ещё под вопросом.)

Posted via ActualForum NNTP Server 1.4

31 авг 11, 19:53    [11208878]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
mayton
Member

Откуда: loopback
Сообщений: 53029
Dimitry Sibiryakov,

да и по записи у меня слишком много вопросов. Как будет синхронизироваться парк машин?
Какой алгоритм согласования текущего номера транзакции или метки времени?
Как будет детектироваться сбой?
31 авг 11, 20:11    [11208922]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54818

mayton
Какой алгоритм согласования текущего номера транзакции или метки времени?

Дык нет никакого согласования. Поскольку не с кем согласовывать. На запись у них работает
только один комп из всего табуна. Он же т.н. "сервер". Всё как в том же мускуле с тем
отличием, что у того "серверов" может быть целых два.

Posted via ActualForum NNTP Server 1.4

31 авг 11, 20:25    [11208965]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
.ЛП
Guest
Dimitry Sibiryakov
Но давайте будем объективны: система авторов действительно имеет определённые достоинства.
Она действительно практически неуничтожима

Давайте будем объективны - система практически неуничтожима при условии, что с ней практически никто не работает :)
А как только начинается интенсивная работа - неуничтожимая система вдруг превращается в неработающую.
Смысл в такой неуничтожимости?

Вот если довести до абсурда...
Можно ведь положить на сервер read-only файл. Каждый клиент его к себе скопирует, и будет на него смотреть внимательным глазом. Тоже неуничтожимая система, кто ж спорит. А толку от такой неуничтожимости?
А до такого абсурда у системы - рукой подать.

Быстро читать система не умеет - потому что она есть append-only лог от ишачьей пасхи до сегодня. Ну, разве что кто-нибудь "компрессировать" её будет периодически. Кто будет компрессировать - тоже непонятно, оно ведь типа как безадминное.
Быстро писать система не умеет - потому что умирает (и сервер, и сеть, и все клиенты сразу).
Зато неуничтожима.
31 авг 11, 20:47    [11209020]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 08/29/2011 02:15 AM, интересующаяся_мнением wrote:

> Очень интересует ваше мнение о строении БД, особенности которой описаны вот
> здесь <http://spcomputer.ru/index.php?option=com_content&task=view&id=26&Itemid=37>

Прочитал всё внимательно и подробно. Всё -- вообще ни о чём.
Начиная с того, что не описано очень многое (например, как вообще данные
удаляются) и кончая тем, что принимаемый подход очень дурацкий.


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

2000 -- это не масштабы для современных БД. Это мизер.
может быть у одного человека больше каких-то более мелких единиц информации,
типа статей начисления. По идее, есть человек, связи его со штатной единицей,
связи штатной единицы со статьями начислений, вот этих связей должно быть
больше. Но это всё равно в 5-10 раз, 20000 статей, ну это уже посолиднее,
но всё равно не впечатляет.


> Я провела интервью с разработчиками комплекса и получила информацию о строении
> БД, которая собственно в статье и описана.

Это вы что ли писали? Извините, местами безграмотно. Как по-русски, так и
технически.

Хотелось бы узнать мнение
> специалистов, особенно тех, кто занимался разработкой или работал с учетными
> системами с одной стороны, и тех, кто глубоко знает теорию БД и обладает
> хорошими именно практическими навыками. Как вам вообще такой подход? Есть в нем
> что-то или как?

В нём не так всё. По сути это самописанный на коленках т.н. pure-MVCC,
прямой аналог -- это Interbase/Firebird. Сильная сторона этого дела --
большая скорость изменений. Новая запись добавляется быстро (если на диск не
писать). Слабые стороны -- это

-- низкая производительность запросов на чтение (надо перебирать все записи
и искать подходящие).
-- низкая эффективность записи в режиме с обеспечением DURABILITY,
потому что каждую (!) запись надо физически (!) писать на диск и дожидаться
отлупа от ОС об окончании записи (!).

Т.е. в итоге если это делать по-нормальному, это плохо и для "пишуших" БД,
и для "читающих". К этому надо ещё добавить проблему удаления записей (старых
версий и удалённых записей), проблему write skew (которую вы вообще никак не
решаете) и пр. Это всё в общем уже давно пройдено в истории развития Interbase.

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

В общем, всё -- бредятина от начала до конца.
У неё есть одно неоспоримое достоинство -- оно, как говорят, как-то работает.

Posted via ActualForum NNTP Server 1.4

31 авг 11, 21:29    [11209125]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Dimitry Sibiryakov
синхронную master-slave репликацию на сотню slave, которые при этом ещё и
остаются доступными на чтение?
MySQL, MS SQL и Oracle это умеют (хотя до определённой версии slave нельзя было читать),
но я не уверен, что они справятся с таким количеством slave. Firebird такого не умеет вообще.

Вах как вы это назвали :)
31 авг 11, 21:46    [11209165]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
FinSoft
...
Я бы предложил немного отвлечься от обсуждения технических подробностей решения и задуматься, а какой смысл сейчас делать подобную архитектуру? Что мы имеем на сегодня. Сильно выросшую производительность компьютеров. ...

Вот именно, и при этом не-производительные компьютеры как-то особенно не продаются. Соответственно при приобретении парка машин для офиса все скоро дойдет до того что даже у секретарши, которой и нужно-то что только документы в ворде набивать, будет стоять двухядерное нечто с 64-х битной архитектурой. Чего ему просто так стоять-то?
Параллельно: нужно нам, пусть даже на пятьдесят человек много-много отчетов считать, причем отчеты такие,что они так или иначе перелопачивают большую часть имеющихся в базе данных. И эти пятьдесят человек еще время от времени в базу все-таки еще что-то заносят и что-то там меняют. Если мы будем все это делать на централизованном сервере - есть вероятность, что нам понадобится что-то довольно мощное, и возможно за приличные деньги. Так чего-б им эти самые много-много отчетов,не считать каждому для себя? Все равно их машины простаивают. И сервер будет не нужен, потому что каждый будет считать этот отчет в монопольном режиме, - тот, который нужен персонально ему.
31 авг 11, 22:02    [11209225]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54818

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

А во время этого просчёта новые данные с сервера будут поступать, или их приём остановится?

Posted via ActualForum NNTP Server 1.4

31 авг 11, 22:12    [11209278]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
интересующаяся_мнением
FinSoft
...
Я бы предложил немного отвлечься от обсуждения технических подробностей решения и задуматься, а какой смысл сейчас делать подобную архитектуру? Что мы имеем на сегодня. Сильно выросшую производительность компьютеров. ...

Вот именно, и при этом не-производительные компьютеры как-то особенно не продаются. Соответственно при приобретении парка машин для офиса все скоро дойдет до того что даже у секретарши, которой и нужно-то что только документы в ворде набивать, будет стоять двухядерное нечто с 64-х битной архитектурой. Чего ему просто так стоять-то?
Параллельно: нужно нам, пусть даже на пятьдесят человек много-много отчетов считать, причем отчеты такие,что они так или иначе перелопачивают большую часть имеющихся в базе данных. И эти пятьдесят человек еще время от времени в базу все-таки еще что-то заносят и что-то там меняют. Если мы будем все это делать на централизованном сервере - есть вероятность, что нам понадобится что-то довольно мощное, и возможно за приличные деньги. Так чего-б им эти самые много-много отчетов,не считать каждому для себя? Все равно их машины простаивают. И сервер будет не нужен, потому что каждый будет считать этот отчет в монопольном режиме, - тот, который нужен персонально ему.
а Вам не приходило в голову, что если всё мировое развитие СУБД идет по другому пути, то тут что-то не так?
как минимум дублирование данных и соответственно их последующая синхронизаций одна из самых неприятных вещей

а кстати где там хранится функционал и что он из себя представляет? т.е. если мне надо допустим добавить какой-то вид документа или какой-нибудь отчетик - что надо делать? куда менять?
31 авг 11, 22:13    [11209283]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Vladimir Baskakov
интересующаяся_мнением
пропущено...

Все агрегаты пересчитывает только сервер. На самом деле примерно так происходит: клиент чего-то наменял, отправил это пакетом на сервере. Сервер почитал все полученное, досчитал все, что можно досчитать только централизованно, записал все что получилось (включая агрегаты и то что прислал клиент) в базу с новым номером транзакции, а потом уже всю эту байду кинул бродкастом всем остальным. Т.о. все всегда имеют агрегаты, соответствующие фактическим данным.

Когда пересчитывает? откуда он знает, что и когда надо (пора) пересчитывать? в традиционных БД - когда сработал триггер... условно. Или - запрос послан не базе, а умному серверу приложений. Принять товар! вписали товар в базу, поправили агрегаты. И этот сервер приложений знает, как на запрос отвечать. И крутится он на машине с мощным железом - сервере... Иногда для таких целей удобно использовать язык хранимых процедур БД.

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

Нуу... на самом деле все где-то близко. Есть ядро - эта вот СУБД,написанная на C++, к ней прилагается фреймворк, ядро которого тоже написано на C++. Фреймворк тесно-тесно взаимодействует с этой БД. Фактически - это один и тот же процесс. На этом фреймворке, уже на встроенном языке написан некоторый системный слой. В частности, к примеру общие процедуры фона, срабатывающие на приход каждой записи. Дальше - тоже на встроенном языке, - уже прикладная логика. Часть этой логики может работать вот в этом самом фоне, - получается как триггер в БД (вот здесь как раз и идет обсчет агрегатов). А часть - быть "клиентской". Какая часть логики отрабатывает, определяется тем - работает все это хозяйство в режиме сервера или клиента. Физически, все эти прикладные утилитки представляют собой просто файлики с определенным расширением, подкладывающиеся в папочки установки фреймворка, таким образом в работающую систему добавляется новая логика - если что-то еще нужно.
31 авг 11, 22:17    [11209297]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Dimitry Sibiryakov
интересующаяся_мнением
каждый будет считать этот отчет в монопольном режиме, - тот, который нужен персонально ему.

А во время этого просчёта новые данные с сервера будут поступать, или их приём остановится?

Будут приниматься. И даже пользователь этой машины сможет работать параллельно, - вбивать что-то, править.. На просчет у клиента создается то, что они называют виртуальной базой, и она фиксирует последний номер транзакции, относительно которого она будет рассматривать данные. Такой вот snapshot получается.
31 авг 11, 22:22    [11209321]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
mayton
Member

Откуда: loopback
Сообщений: 53029
Dimitry Sibiryakov
mayton
Какой алгоритм согласования текущего номера транзакции или метки времени?

Дык нет никакого согласования. Поскольку не с кем согласовывать. На запись у них работает
только один комп из всего табуна. Он же т.н. "сервер". Всё как в том же мускуле с тем
отличием, что у того "серверов" может быть целых два.

Мне это больше напоминает вариант PostgreSQL в самой своей плохой инкарнации.
т.е. без возможности использовать вакуум сегмента таблиц и вдобавок без
поддержки стандарта Ansi SQL.
31 авг 11, 22:25    [11209340]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 08/29/2011 01:43 PM, интересующаяся_мнением wrote:

>
> Ммм.. да. Скорее всего. Так и не позиционируется это для больших нагрузок на
> запись.

А на кой фиг оно кому надо в таком случае ?

> У Аксес я так понимаю все-таки проблемы с многопользовательностью? Или нет?
> А вот с этим я кстати не согласна. Тот же Access используется очень широко. И

Всё верно. Только используется он как клиент к какой-то клиент-серверной СУБД,
особенно к MSSQLServer. Собственно, все десктопные СУБД (выжившие) поступают
точно так же -- ходят к серверу.

> Ну я так понимаю не только "адынэсовцы" :) На другие системы бухгалтера еще
> больше плюются, тот же Парус к примеру. Какие бы жопорукие они не были, но они -
> лучшее что есть на рынке из массовых продуктов именно для нашей бухгалтерии, как
> я понимаю.

Парус, 1С -- бывшие десктопы. Там подходы такие -- всё тянется на клиента,
обрабатывается. Ваша эта штука сумела сделать то же самое, что и
клиент-серверные СУБД -- поместить обработку данных и сами данные в одно и то же
место.
Только сделала она это ровно обратным к нормальному образом -- и то, и другое --
на клиенте. У вас да, с обработкой уже проблем нет, но будут проблемы с пишушими
транзакциями, они будут очень тяжёлыми. Сейчас оно работает, только потому что
транзакции сами никакие. Будет серьёзная нагрузка -- это всё очень быстро ляжет,
потому что выполняемая при этом работа квадратично растёт с ростом пользователей.

Posted via ActualForum NNTP Server 1.4

31 авг 11, 22:28    [11209351]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 08/29/2011 02:08 PM, Yo.! wrote:

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

Видимо, для этого клиент должен послать вместе с запросом идентификатор
транзакции БД, относительно которой выполняется данная следующая транзакция.
Если на сервере уже выполнилась следующая транзакция, то этой дадут отлуп
(что само по себе уже ужас, пользователям-то как договариваться ? Голосом
разве ...)

Posted via ActualForum NNTP Server 1.4

31 авг 11, 22:31    [11209362]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 08/29/2011 02:28 PM, интересующаяся_мнением wrote:

> при отладке комплекса. Если перевести станцию в локальный режим работы, то вам в
> теории ничего не мешает начать кромсать данные в базе как вам заблогарассудится
> - типа - эксперименты проводить. Вы можете этим часами заниматься. А потом
> просто сказать что-то типа undo и система у вас вернется в начальное состояние.
> В теории - так же просто делать и пошаговый undo и на заданный момент времени.
> Как вот эту, например фичу реализовать в стандартном реляционнике, вот без
> такого потокового метода записи - я не представляю, - накладные расходы слишком
> большими будут.

Очень просто. Любая ACID-СУБД это вам даст сделать.
Начинаете транзакцию.

Эксперементируете, эксперементируете...

проверяете, что там.

откатываете транзакцию.

Posted via ActualForum NNTP Server 1.4

31 авг 11, 22:35    [11209383]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 08/29/2011 02:47 PM, Gluk (Kazan) wrote:

> То есть 200 внедрений это НЕ серьезно?

200 внедрений -- это супер.

Posted via ActualForum NNTP Server 1.4

31 авг 11, 22:37    [11209387]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 08/29/2011 03:10 PM, интересующаяся_мнением wrote:

> Взять к примеру, переменное число полей в таблицах. Де-факто получается, что у
> них просто очень широкие таблицы, в которые напихано сразу все. В теории, - ну
> что мешает сделать это в реляционной СУБД? Тем более что ALTER TABLE, насколько
> я понимаю, операция простая и в современных СУБД ресурсов не требует особо, а
> значения с NULL память не забивают.. Так почему не делают? Некошерно? Некрасиво?
> Почему?

На хрен никому не нужно потому что.
Ну и потом -- это легко только если поле NULL или хранение записей поколоночное.
В остальных случаях это очень даже нелегко.

Ну и дизайн БД с широченными таблицами безграмотный и нигде неприменим по-хорошему.

> С вычислениями агрегатов на лету, - опять то же самое. Я понимаю, что в теории
> ничто не мешает в современной БД повесить всю эту обработку на триггера. Но
> почему-то тоже особо не делают. Почему?

Почему не делают-то ? Материализированные VIEW, вычисляемые колонки -- всё есть.


Posted via ActualForum NNTP Server 1.4

31 авг 11, 22:43    [11209407]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
.ЛП
Guest
SergSuper
а Вам не приходило в голову, что если всё мировое развитие СУБД идет по другому пути, то тут что-то не так?

SergSuper, а тебе не приходило в голову, что весь мир идёт немного не в туда? :)
Аргументы то правильные высказываются.
Ну в самом деле. На самом обычном дохленьком офисном ПК вполне можно термоядерные реакции считать, в реальном времени. Самый мощщный когда-то Deep Blue, обыгравший Каспарова в шахматы, в подмётки не годится тому, что сейчас на столе у секретарш пылится.
Понятно, что половину из этих немерянных мощщей отожрёт подсветка синтаксических ошибок в ворде :), но другая то половина останется. Чего добру зря пропадать?

Сами идеи вполне съедобные. Но реализация...

Было бы оно в виде например таком:
Сервер. По ходу дела считающий фсякие там агрегаты, олаповские кубики, и прочую шляпу. Отдающий готовые кубики по первому требованию.
Клиент. С локальной копией нужных данных, всех, или только частично каких-то. MS SQL Server Compact, FB Embedded, etc. В нормальной реализации, а не в виде никому никуда не упершегося аппенд-онли лога.
Настраиваемая служба нотификаций. Где можно подписаться на всё, подписаться на что-то, отписаться от чего-то, отписаться от всего.
Ну и было бы о чём говорить.

А тут блин этттаа... "Абстрагировались от знаний" :)
31 авг 11, 22:43    [11209409]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
MasterZiv
Парус, 1С -- бывшие десктопы. Там подходы такие -- всё тянется на клиента,
обрабатывается. Ваша эта штука сумела сделать то же самое, что и
клиент-серверные СУБД -- поместить обработку данных и сами данные в одно и то же
место.
Только сделала она это ровно обратным к нормальному образом -- и то, и другое --
на клиенте. У вас да, с обработкой уже проблем нет, но будут проблемы с пишушими
транзакциями, они будут очень тяжёлыми. Сейчас оно работает, только потому что
транзакции сами никакие. Будет серьёзная нагрузка -- это всё очень быстро ляжет,
потому что выполняемая при этом работа квадратично растёт с ростом пользователей.


А вот за этот коммент - спасибо. Над ним стоит подумать. Т.е. вы хотите сказать, что 1C и Парус сначала делают массово тяжелые селекты, потом считают все на клиенте, а потом кладут обратно да еще и транзакцию скорее всего на всю эту байду держат?
31 авг 11, 22:49    [11209428]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить