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

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

интересующаяся_мнением
На просчет у клиента создается то, что они называют виртуальной базой, и она фиксирует
последний номер транзакции, относительно которого она будет рассматривать данные. Такой
вот snapshot получается.

Ну, с файлом данных всё ясно: читатели не читают там, куда пишут писатели. А вот как
индексы умудряются обновляться? В+ дерево же последовательно не допишешь, там всяко
рандомный доступ, разделение страниц и прочие прелести, читателей нервирующие.

Posted via ActualForum NNTP Server 1.4

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

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

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

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

Ага, всё верно. Только для этого немного-немало надо транзакции сериализовать
и непротиворечивость с локальными изменениями проверить.

И сделать это (ещё раз повторяю) на N машинах. N машин делает по одному
изменению, которые идут на N машин, получается N**2 работы.

У обычных нормальных СУБД это просто kN.


> Может, но, во-первых это критично только в случаях конфликта на обновление.

Есть Конфликт или нет -- надо ещё обнаружить, между прочим.

Если
> идет массовая вставка данных - какая разница в каком порядке они вставятся?

Есть нюансы.

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

Нет. Есть и блокировки (т.н. pessimistic locking) и optimistic locking тоже.

Posted via ActualForum NNTP Server 1.4

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

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

.ЛП
SergSuper
а Вам не приходило в голову, что если всё мировое развитие СУБД идет по другому пути, то тут что-то не так?

SergSuper, а тебе не приходило в голову, что весь мир идёт немного не в туда? :)
нет, я эволюционист )
31 авг 11, 22:57    [11209462]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

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

On 08/29/2011 04:56 PM, интересующаяся_мнением wrote:
> И еще момент: далеко не каждый магазин средней паршивости может позволить себе
> даже SQL Server, не говоря уж об Oracle... Есть и еще один момент: у нас сейчас
> направление партии и правительства - уход с Win в госучреждениях. Это решение
> вроде как в теории может пойти на чем угодно. Максимум - небольшой допил
> потребуется на особенности компиллятора C++.

Дофига хороших бесплатных СУБД. PG например, под тот же 1C.
Люди вон на одном линуксе и PG работают, покупается только 1С.

Posted via ActualForum NNTP Server 1.4

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

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

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

> Обсудила, уточнила. Да, клиент будет ждать ответа с сервера. Но это не помешает
> ему заниматься другими задачами параллельно. В других окнах, - а ожидание будет
> происходить только в одном окне.

Эт как ? Ему надо транзакцию коммитить, чтобы было от чего плясать для следующей
транзакции. А если он будет плясать от предыдущей, то транзакция заведомо будет
не принята. Нет, он ждать должен.


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

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

Но лог транзакций то общий, соответственно на запись в него - очередь.

Да. Запись в лог -- узкое место всех ACID-баз.

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

Не понимаете, что на диск пишется только лог. Данные не обязаны быть записаны
по концу транзакции.

Ещё не понимаете, что лога вообще может не быть, но это ещё хуже --
все записи должны физически быть записаны на диск -- это фактически уже
катастрофа для СУБД.

Posted via ActualForum NNTP Server 1.4

31 авг 11, 23:04    [11209485]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
.ЛП
Было бы оно в виде например таком:
Сервер. По ходу дела считающий фсякие там агрегаты, олаповские кубики, и прочую шляпу. Отдающий готовые кубики по первому требованию.
Клиент. С локальной копией нужных данных, всех, или только частично каких-то. MS SQL Server Compact, FB Embedded, etc. В нормальной реализации, а не в виде никому никуда не упершегося аппенд-онли лога.
Настраиваемая служба нотификаций. Где можно подписаться на всё, подписаться на что-то, отписаться от чего-то, отписаться от всего.
Ну и было бы о чём говорить.

Примерно так это и делается в некоторых BI решениях, только без Embedded сервера на клиенте, насколько я понимаю, - просто кэшами в памяти. Просто в такой конфигурации клиент только читающим получается... (дальше мысль идет) ну наверно, можно сделать так шоб и писал - но это у вас тогда с клиента прямой коннект на сервер.... а иначе замучаетесь синхронизировать :)
31 авг 11, 23:05    [11209487]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

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

On 08/29/2011 05:58 PM, интересующаяся_мнением wrote:
> Индексы обновляются при поступлении новых записей. Сначала, - пока транзакция не
> зафиксирована - только о оперативной памяти. Потом, после завершения всех
> операций по транзакции - сброс на диск.

Не ACID уже. Ну да ладно.

> клиентах. Т.е. сервер клиентам индексы не пересылает, они его сами создают при
> записи оновлений в свою базу.

Ну вот, ещё раз работу на N помножили.


> У меня ответный вопрос про "одним чтением". А физически - это как? К примеру -
> вот у вас таблица в сотню тысяч записей. Откуда вы вот так вот сразу узнаете в
> каком месте таблицы находится искомая запись?

В индексе лежит физический адрес записи.

Posted via ActualForum NNTP Server 1.4

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

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

On 08/30/2011 12:13 AM, интересующаяся_мнением wrote:

> Вот чего я нефига не могу понять: почему комплекс, написанный на этой базке,
> которая вроде бы такая примитивная, обслуживая задачи того же класса, что и все
> наши промышленные бухгалтерские системы, сидящие на этих самых реляционных СУБД
> (1C - Mssql, Парус - Oracle), и автоматизируя кучу всевозможных рассчетов,
> которые эти системы не автоматизируют, имеет: размеры базы сильно ниже, скорости
> обработки существенно выше. В чем тут дело? Мне думается что тут играет
> следующее: их совершенно безумные структуры в базе (очень широкие и разреженные
> таблицы), как следствие - существенно меньше джойнов по таблицам.

Вы знаете, я расскажу историю из моего опыта. Я занимался автоматизацией
выставления счетов за выполненные работы. Старая версия была на клиппере
и "работала быстро" по словам пользователей (и они не врали). Новая версия
была на клиент-серверной СУБД, и работала действительно небыстро по сравнению
со старой. Теперь скажу почему. Основная задача -- найти для описанной работы
нужный тариф и, взяв из него сумму, сформировать счёт. Новая программа
подбирала тариф автоматически. В старой программе тариф оператор выбирал
руками при вбивании работы. Люди держали в голове что-то около сотни позиций
тарифного справочника и отдел из 5-7 человек только этим и занимался.

Я конечно не знаю, но вполне возможно в вашем случае также имеет место
такая "оптимизация производительности". А вот 1с или парус можно наверное
упрекнуть во многом, кроме отсутствия универсальности -- без неё они бы
просто не выжили.

Posted via ActualForum NNTP Server 1.4

31 авг 11, 23:18    [11209523]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Dimitry Sibiryakov
интересующаяся_мнением
На просчет у клиента создается то, что они называют виртуальной базой, и она фиксирует
последний номер транзакции, относительно которого она будет рассматривать данные. Такой
вот snapshot получается.

Ну, с файлом данных всё ясно: читатели не читают там, куда пишут писатели. А вот как
индексы умудряются обновляться? В+ дерево же последовательно не допишешь, там всяко
рандомный доступ, разделение страниц и прочие прелести, читателей нервирующие.

Честно - детали я не очень поняла, но примерно там происходит следующее:
1. Индекс для читателя. В индексе на самом деле на самом низком системном уровне содержится информация обо всех версиях измененных записей. При поиске данных по индексу поиск осуществляется тоже с учетом этого последнего номера транзакции.
2. При приходе транзакции с сервера, сначала все это делается тоже в некотором виртуальном пространстве: и база достраивается и кусок индекса для новой транзакции создается, а потом уже, при реальной записи все это соединяется с тем индексом, который в файле.

Если нужно детальнее - я могу эту ситуацию провинтилировать еще отдельно.
31 авг 11, 23:20    [11209530]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

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

On 08/30/2011 12:13 AM, интересующаяся_мнением wrote:
> реализует... Городят кучу доп. структур для хранения метаданных, динамических
> параметров и т.п. А разработчики Викты в таких случаях не парятся и просто
> хреначят в таблицу, к примеру, счетов, очередной аттрибут и все. И вот тут мне
> как раз хочется услышать тех, кто сам писал учетные системы ну или близко с ними
> знаком: почему строят кучу доп. таблиц для метаданных и делают динамические
> параметры на EAV, к примеру или наследуемых таблицах? Почему это нельзя сделать
> проще именно в стандартной реляционной базе? Что мешает? Ну понадобился тебе
> очередной аттрибут - ну сделай ты alter table и вот тебе под него место. Почему
> так нельзя?

Потому что жизнь гораздо сложнее, чем вы её тут описали, и "вхренячить" ещё
один атрибут чаще всего -- не решение. Если можно вхренячить -- вхренячиваем.

Posted via ActualForum NNTP Server 1.4

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

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

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

Поищите в интернете информацию на тему терминальных станций, там все расписано.
Если Вам при построении отчетов нужно перелопачивать много данных, то это проблемы прикладного решения. Бизнес-информация носит периодический характер, поэтому отчетные периоды принято закрывать и сохранять готовые итоги для быстрого получения информации. Зачем считать бухгалтерский баланс за прошлый год, если его можно один раз сохранить по завершению года, а затем выдавать в готовом виде? Кроме этого надо учитывать, что при централизованной обработке при таком количестве пользователей все дневные обращения к базе оседают в кэше ОС, общем для всех пользователей. То есть читать все будут не с диска, а из ОЗУ. Ну и работу с отчетами можно оптимизировать. Если их много-много, то, возможно, разные пользователи формируют их с одними и теми-же параметрами. Сделайте так, чтобы в этом случае можно было брать готовый результат у другого пользователя, и обращений к базе не потребуется. По моему опыту, на 20-25 рабочих мест годится обычный бюджетный компьютер с 2 ядрами и 2ГБ ОЗУ. Сейчас уже 6-ядерные процессоры в продаже и ждут на подходе 12-ядерные. ОЗУ меньше 4ГБ на сервер ставить не принято. В общем, задумайтесь. Успехов.
31 авг 11, 23:22    [11209538]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

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

On 08/30/2011 01:15 PM, Siemargl wrote:

> А так - небольшие системы все прожуют. Не зря же в 1С 8, сделали свой новый
> файловый механизм БД.

Здесь-то не файл-сервер, а как-то типа клиент-сервер-наоборот.

Posted via ActualForum NNTP Server 1.4

31 авг 11, 23:25    [11209548]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
.ЛП
Guest
FinSoft
Сейчас уже 6-ядерные процессоры в продаже и ждут на подходе 12-ядерные. ОЗУ меньше 4ГБ на сервер ставить не принято. В общем, задумайтесь. Успехов.

Вы кажется не поняли :)
Сейчас меньше 4ГБ не принято ставить даже на клиента.
О чём и речь - каждый клиент сам себе мега-мозг, а вы тут ведёте какие-то разговоры за бедность, о терминальных службах, дохленьких компутерах и одном могучем сервере.
31 авг 11, 23:27    [11209550]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

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

интересующаяся_мнением
Если нужно детальнее - я могу эту ситуацию провинтилировать еще отдельно.

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

Posted via ActualForum NNTP Server 1.4

31 авг 11, 23:33    [11209566]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
.ЛП
Guest
интересующаяся_мнением
.ЛП
Было бы оно в виде например таком:
Сервер. По ходу дела считающий фсякие там агрегаты, олаповские кубики, и прочую шляпу. Отдающий готовые кубики по первому требованию.
Клиент. С локальной копией нужных данных, всех, или только частично каких-то. MS SQL Server Compact, FB Embedded, etc. В нормальной реализации, а не в виде никому никуда не упершегося аппенд-онли лога.
Настраиваемая служба нотификаций. Где можно подписаться на всё, подписаться на что-то, отписаться от чего-то, отписаться от всего.
Ну и было бы о чём говорить.

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

Если говорить в контексте обсуждения вашей системы - ну да, надо постоянный коннет к серверу. Ну так ведь и у вас надо постоянный коннект к серверу. Ну да, иначе замучаешься с синхронизацией. Ну так ведь и у вас есть конфликты синхронизации, даже несмотря на наличие постоянного коннекта к серверу.
31 авг 11, 23:34    [11209569]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

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

On 08/31/2011 05:50 PM, .ЛП wrote:

> Мы тут что обсуждаем, СУБД, или условия задачи?

> Однако же вопрос стоял "Что вы думаете по поводу вот такой СУБД".
> Ответ - "Она ужасна. Потому что способна работать только вот в таких вот
> условиях, и даже при выполнении этих условий не видно преимуществ по сравнению с
> любой другой".

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

Posted via ActualForum NNTP Server 1.4

31 авг 11, 23:34    [11209570]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
MasterZiv
On 08/30/2011 12:13 AM, интересующаяся_мнением wrote:
Я конечно не знаю, но вполне возможно в вашем случае также имеет место
такая "оптимизация производительности". А вот 1с или парус можно наверное
упрекнуть во многом, кроме отсутствия универсальности -- без неё они бы
просто не выжили.

Да в том-то и дело что нет! Эта самая система делает больше и автоматизирует больше операций чем 1С и Парус. Это подтверждают клиенты, которые по настоянию начальства переходили на эти продукты. Они потом звонят и плачутся, что вот в этой системе на Викте все было автоматизировано, а тут им приходится ручками считать, - они на это дополнительных бухгалтеров были вынуждены на работу брать. Даже случаи возвратов с 1С на эту систему были, несмотря на то что предыдущая версия, в которой полный учет предприятия реализован сделана еще (шшшш.... в DOS-е) Все случаи уходов с этой системы происходили исключительно по политическим причинам и зачастую сопровождались забастовками бухгалтеров.

Насчет универсальности - это тоже не так. Есть люди, которые продавали эту систему а потом еще стали продавать 1С. Они не перестают плеваться - говорят там настроить ничего невозможно, то что в системе на Викте влет делалось. Сидят на 1С исключительно по политическим причинам - ее продать легче.

Вы знаете что я делаю на этом форуме? Пытаюсь понять какого хрена вся эта байда так работает. Где то зерно, которое нужно выделять.
31 авг 11, 23:35    [11209573]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
.ЛП
Guest
интересующаяся_мнением
MasterZiv
On 08/30/2011 12:13 AM, интересующаяся_мнением wrote:
Я конечно не знаю, но вполне возможно в вашем случае также имеет место
такая "оптимизация производительности". А вот 1с или парус можно наверное
упрекнуть во многом, кроме отсутствия универсальности -- без неё они бы
просто не выжили.

Да в том-то и дело что нет! Эта самая система делает больше и автоматизирует больше операций чем 1С и Парус. Это подтверждают клиенты, которые по настоянию начальства переходили на эти продукты. Они потом звонят и плачутся, что вот в этой системе на Викте все было автоматизировано, а тут им приходится ручками считать, - они на это дополнительных бухгалтеров были вынуждены на работу брать. Даже случаи возвратов с 1С на эту систему были, несмотря на то что предыдущая версия, в которой полный учет предприятия реализован сделана еще (шшшш.... в DOS-е) Все случаи уходов с этой системы происходили исключительно по политическим причинам и зачастую сопровождались забастовками бухгалтеров.

Насчет универсальности - это тоже не так. Есть люди, которые продавали эту систему а потом еще стали продавать 1С. Они не перестают плеваться - говорят там настроить ничего невозможно, то что в системе на Викте влет делалось. Сидят на 1С исключительно по политическим причинам - ее продать легче.

Очень хорошо.
Значит кто-то умудрился написать хороший фреймворк, или как вы там его называете. Хороший, универсальный, кастомизируемый, весь из себя расчудесный, формочки, кнопочки, проводки, обороты, остатки, агрегаты, кубики, и фунт прованского масла сбоку.

Но это всё, вот все эти проводки, фреймворки, формочки, кнопочки - они не имеют отношения к СУБД. А здешний раздел форума - именно про СУБД.
Про фреймворки, кнопочки, формочки, проводочки - есть другие разделы. Разработка информационных систем. ERP системы. С подфорумом 1С. Пойдите туда, спросите, почему 1С медленно и не универсально, а у вас быстро и универсально. Или не спросите, а наоборот расскажите.
Сюда же это не особо надо писать. Здесь СУБД обсуждается. Плюсы вашей информационной системы, как мне кажется, они не благодаря, а вопреки используемой СУБД.

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

Есть зерно, которое надо сначала выделить, а потом выкинуть :)
СУБД.
31 авг 11, 23:48    [11209624]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

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

On 08/31/2011 11:49 PM, интересующаяся_мнением wrote:

> А вот за этот коммент - спасибо. Над ним стоит подумать. Т.е. вы хотите сказать,
> что 1C и Парус сначала делают массово тяжелые селекты, потом считают все на
> клиенте, а потом кладут обратно да еще и транзакцию скорее всего на всю эту
> байду держат?

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

Но я не большой знаток этих штук, тут надо держать руку на пульсе.

Posted via ActualForum NNTP Server 1.4

31 авг 11, 23:53    [11209633]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
.ЛП
Значит кто-то умудрился написать хороший фреймворк, или как вы там его называете. Хороший, универсальный, кастомизируемый, весь из себя расчудесный, формочки, кнопочки, проводки, обороты, остатки, агрегаты, кубики, и фунт прованского масла сбоку.


MasterZiv
В общем-то, да. В 1С вся обработка идёт на их языке, на клиенте.
Бежится по всем записям и обрабатывается. Правда они делали новые


Суммируем 2+2. 1С такой тормоз, потому что начинался как файл-серверный, а при переходе на клиент-сервер сохранил предыдущие принципы и подходы к обработке, - переписать было слишком дорого, потому что "вся обработка ведется на их языке"

В Викте: "значит кто-то умудрился написать хороший фреймворк"... Трабель в том, что этот самый фреймворк неофигенно переплетен с БД и "вся обработка ведется на их языке, на клиенте". Выкинуть БД=переписать все или получить болячки 1С.

Однако: Викта-таки сделала то, что не сделал в свое время 1С положившись на файл-серверную реализацию: а именно "сложила данные и их обработку в одно место", пусть и сделав это шиворот навыворот - именно этот факт, позволяет ей совершать обработку быстрее и делать больше, чем аналогичные продукты на схожих объемах. И это же, кстати, позволило ей легко наращивать функционал: при добавлении отчетов, они оформляются утилитками на встроенном языке и подкладываются к системе в виде очередного дополнительного модуля... и обрабатываются там же, где лежат данные.
Где-то так у меня получилось.

Все правильно - она заткнется, если объем данных или скорее изменений данных превысит какой-то определенный лимит. Кстати, насчет объемов - я наверно не очень хороший пример приводила про рассчет зарплаты: там ведь на самом деле очень сложная логика, - каждый человек по отдельности считается, - с учетом кучи всяких параметров (отпуска, стаж, премии, календарь, рабочие часы и т.п.). Просто с точки зрения бух. учета это довольно сложная операция, поэтому она и приводится в пример.
Другой пример - оборотно-сальдовая ведомость за год на примерно 400 тыс. документов, - тоже около 2-х минут.

При этом, если рассматривать вариант клиент-сервер, то для того, чтобы обеспечить должную эффективность, нам по идее, нужно наращивать функционал тоже на сервере, в виде хранимых процедур, например. И сделать клиента совсем-совсем глупеньким. Тогда другие фишки потеряются: у них ведь как, - вот работает система. Раз чего-то не получается. Ты - раз в обработчик, подправил алгоритм и все правильно теперь считается. Если ХП на сервере - пользователь так просто уже не залезет (Не бейте меня камнями :) Я знаю, что с точки зрения безопасности и защиты системы - это зло :) ). Отчета нехватает - раз, - тут же формочку слабал, формулки навесил, алгоритм какой-то вычислений если что-то сложное - система всосала и продолжает работать... Это примерно как сайт развиваешь: не хватает чего-нибудь. Ты раз JSP-шку, повесил на сайт и вот она у тебя уже включилась в работу, свою логику какую-то исполняет... Только здесь еще и компилляция на лету и пошаговый отладчик если что... А все старое как работало, так и продолжает работать.
Если все это разбивать на клиент-сервер... сложно получается вот с такими вот фишками. Можно конечно прослойки, API для доступа к данным... Но они все-равно будут ограниченными... и все равно будут тянуть данные на клиента, чтобы потом на клиенте же их и обрабатывать.
1 сен 11, 00:49    [11209752]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
интересующаяся_мнением
Да в том-то и дело что нет! Эта самая система делает больше и автоматизирует больше операций чем 1С и Парус. Это подтверждают клиенты, которые по настоянию начальства переходили на эти продукты. Они потом звонят и плачутся, что вот в этой системе на Викте все было автоматизировано, а тут им приходится ручками считать, - они на это дополнительных бухгалтеров были вынуждены на работу брать. Даже случаи возвратов с 1С на эту систему были, несмотря на то что предыдущая версия, в которой полный учет предприятия реализован сделана еще (шшшш.... в DOS-е) Все случаи уходов с этой системы происходили исключительно по политическим причинам и зачастую сопровождались забастовками бухгалтеров.
но судя по сайту, реализовано только 4 направления:
Расчет заработной платы
Питание
Электронный деканат
Учет кадров

я ни в 1С, ни в производственной бухгалтерии не силен(точнее полный ноль), но что-то мне подсказывает что 1С умеет несколько больше

может всё-таки уход был не по политическим мотивам, а действительно требовалась другая функциональность?
1 сен 11, 01:29    [11209822]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
.ЛП
Guest
интересующаяся_мнением
Суммируем 2+2. 1С такой тормоз, потому что начинался как файл-серверный, а при переходе на клиент-сервер сохранил предыдущие принципы и подходы к обработке

Вы чего-то как-то не так суммируете. И вообще непонятно откуда взяли вот это вот.
Файл-серверность и тормоза 1С слабо связаны.
Есть же куча самописных учётных систем, в том числе на файл-серверной архитектуре. Которые тормозами не страдают. Курсорную обработку если б упомянули, еще понятно было бы, но курсоры и файл-серверы - это совсем не синонимы, и даже не из одной оперы.

Есть учётные системы и файл-серверные, не страдающие тормозами, и клиент-серверные не страдающие тормозами, и клиент-серверные, страдающие тормозами, и файл-серверные, страдающие тормозами.
Вот 1С - пример тормоза и в файл-серверной, и в клиент-серверной инкарнации.

Как вам уже неоднократно было сказано, тормоза или нетормоза учётной системы, всяких там расчётов зарплат аж на тысячу сотрудников, и прочих рабочих мест тридцати бухгалтеров - они вообще практически никак не кореллируют с СУБД. Ни с СУБД, ни с файл-серверной или клиент-серверной архитектурой, ни со способом хранения в виде XML-файла или аппенд-онли лога.

Вы не там пытаетесь выкопать ответ на вопрос "почему 1С тормозит".

В Викте: "значит кто-то умудрился написать хороший фреймворк"... Трабель в том, что этот самый фреймворк неофигенно переплетен с БД

Это плохо.

Однако: Викта-таки сделала то, что не сделал в свое время 1С положившись на файл-серверную реализацию: а именно "сложила данные и их обработку в одно место"

Глупость какую-то очередную пишете.
Данные и их обработка - всегда в одном и том же месте. По другому в принципе невозможно. Если там, где происходит обработка, нету данных - то и обрабатывать нечего.
1 сен 11, 01:41    [11209837]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
А тут конфликты... слишком сложная логика выходит. Пусть уж лучше человек объявляет - это теперь сервер, - его не выключать.


Это называется - позиция страуса :)
Закопать голову в песок, дабы не видеть проблемы (и админ не нужен, да )
1 сен 11, 08:56    [11209994]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
Shlippenbaranus
Вооот. Достоинство этой системы - ей сисадмина не надо. Все равно сидит и курит. И никуя не делает :).

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


Я продолжительное время работал админом у местного Internet-провайдера. Таки да, большую часть времени занимался фигней: дорабатывал отчеты, цапался со всеми начальниками отделов по поводу постановок задач, разбирал полеты с особо буйными абонентами

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

Но так да, Вы абсолютно правы (большую часть времени) (кажется, что) админ не нужен
1 сен 11, 09:04    [11210013]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Vladimir Baskakov
Ага... начинаю понимать. В переводе на эскуэль - сделал апдейт или инсерт - сделай селект и сравни, то ли заселектилось, что ты изменял, или нет... да.


Да не, все проще. Просто в update добавляются дополнительные проверки (по тем полям, которые не меняли). Если update изменил 0 строк - значит строку успел поменять кто-то другой и надо перечитать. Ну а на счет библиотек, как правило прямым DML в базу редко кто пользуется.
1 сен 11, 09:07    [11210017]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить