Здравствуйте, DarkGray, Вы писали:
DG>>>Итого цена получилась 3000 * 2-5 * 3-10 * 3-10 * 2-5 ~ 700000$, число, конечно, не очень большое, но довольно ощутимое, для отдельно взятой средней фирмы. S>> 6-9 килобаксов.
DG>128гб? ссылку, пожалуйста. http://www.amdnow.ru/reviews/hammer/index6.shtml
DG>>>Если же, например, описания идут не plain-текст, а rich-текстом (doc, html, xml), то описание уже может быть и 2000 символов, и четыре тысячи, а ведь скорее всего захочется и full-text index по этим описаниям- это еще одна копия этих же данных и т.д. S>> А кто предлагал использовать doc, html, xml.
DG>Пользователь.
S>> Речь идет о несколько другой организации хранения данных и работа с данными как в локальных базас с ООП надстройкой над хранимыми данными и обрабокой на стороне сервера. Теже ECO ObjectSpace работают только на стороне клиента. На стороне сервера этого нет. Для объектного подхода нужени быстрый доступ по ссылкам а это можно решить введение прямой ссылки (номер записи)
DG>Что мешает сделать индекс для реляционной базы, который будет хранить эту прямую ссылку?
Это вопрос к разработчикам. Есть проблемы при обмене с базами, когда вместо прямой ссылки нужно подставлять другой PK для обмена данными. DG>ИМХО, проблема не в прямых ссылках, а в том, что реляционная база не поддерживает полиморфизм. DG>Если у нас есть таблица "одежда", и таблица "еда", то сделать таблицу "отгружаемый товар" — очень тяжело. DG>Потому что реляционная база не поддерживает ссылкы на разнотипные (из разных таблиц) данные.
DG>Но может это просто стоит прикрутить к реляционное базе?
Тоже не проблема, но упирается все в SQL а в нем все беды такого подхода. А подход работы как с локальными базами отметается из- за безопасности (неизвестно что ты будешь воротить в адресном пространстве сервера, но это уже проблемы разработчика) и вообще то нужна компиляция всех связей в том числе и построенных на таблицах объектов.
А вот на локальной БД все это строится легко и скорость очень высокая без всякой статистики и оптимизаторов, но понятно что надежность несколько хуже и для эмуляции клиент сервера применяют TSE что бы уменьшить трафик и использовать кэширование файлов, либо самому организовывать сервер например на DCOM или сокетах. Но нужно делать еще огромный пласт по синхронизации, транзакциям итд но решаемо.
Особенно если делать свою базу. Но это так отход от темы.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
DG>>>>Итого цена получилась 3000 * 2-5 * 3-10 * 3-10 * 2-5 ~ 700000$, число, конечно, не очень большое, но довольно ощутимое, для отдельно взятой средней фирмы. S>>> 6-9 килобаксов.
DG>>128гб? ссылку, пожалуйста. S>http://www.amdnow.ru/reviews/hammer/index6.shtml
И где там написано, что 128гб памяти стоит 6 килобаксов?
Там только написано:
В результате, память для программ представляется одним целым, так же, как и в обычных SMP-системах. Максимальный ее объем в 8-процессорной системе составит 128 Гбайт(!), поскольку каждый из процессоров SledgeHammer в состоянии использовать максимум 8 модулей памяти по 2 Гбайт каждый.
S> А вот на локальной БД все это строится легко и скорость очень высокая без всякой статистики и оптимизаторов,
Скорость высокая, только пока запросы, используются только те, что задумал разработчик, как только пользователь захотел подергать нестандартные запросы, то база построенная по такой схеме — либо, вообще, не может выполнить такие запросы, либо сильно проседает по производительности.
Здравствуйте, DarkGray, Вы писали:
S>> Да огромная цифра. Есть фирмы с множеством складов по 20 компьютеров и у каждого очередь. И работали на DBASE но это простейшие операции где сложный расчет не нужен.
DG>Такие базы очень примитивные, и плохо покрывают реальные запросы менеджеров. DG>Менеджера интересуют следующие фичи: DG>1. На сколько эффективно используется складское помещение? DG>2. Автоматическое формирование цены на основе ряда показателей (закупочная цена, налоги, курс валюты) DG>3. Кластеризация покупателей, а также стандартная корзина каждого кластера DG>4. Оплата платежей, используя пластиковые карточки, корпоративные счета и т.д. DG>5. Гибкая система формирования скидок. DG>и т.д.
5. План закупок на основании продаваемости товара и его остатков и периодичности поставок итд.
Вот все перечисленное тобой вещи не составляют больших проблем и любой программист 1С щелкает все это как семечки. Проблемы возникают с организацией сложных расчетов при проведении документа. Обычно поступают так документы проводятся с минимальными рассчетами а в конце дня по ним формируются сложные проводки но уже с сгруппированными данными или консолидируются в другой базе где работа ведется с общими данными уже сгруппированными для нормального учета. В том числе и олап. В принципе даже желательно разбивать на отдельные специализированные базы и 1 универсальную.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, DarkGray, Вы писали:
DG>>>>>Итого цена получилась 3000 * 2-5 * 3-10 * 3-10 * 2-5 ~ 700000$, число, конечно, не очень большое, но довольно ощутимое, для отдельно взятой средней фирмы. S>>>> 6-9 килобаксов.
DG>>>128гб? ссылку, пожалуйста. S>>http://www.amdnow.ru/reviews/hammer/index6.shtml
DG>И где там написано, что 128гб памяти стоит 6 килобаксов?
Прошу прощения ошибся на порядок. Ну у отдельно взятой фирмы и объем баз несколько другой.
DG>Там только написано: DG>
DG>В результате, память для программ представляется одним целым, так же, как и в обычных SMP-системах. Максимальный ее объем в 8-процессорной системе составит 128 Гбайт(!), поскольку каждый из процессоров SledgeHammer в состоянии использовать максимум 8 модулей памяти по 2 Гбайт каждый.
Уже есть 32ГБ а про 128 был ответ на ограничение на 64 ГБ для IA64. S>> А вот на локальной БД все это строится легко и скорость очень высокая без всякой статистики и оптимизаторов,
DG>Скорость высокая, только пока запросы, используются только те, что задумал разработчик, как только пользователь захотел подергать нестандартные запросы, то база построенная по такой схеме — либо, вообще, не может выполнить такие запросы, либо сильно проседает по производительности.
Ну да в Парусе,Навижн, Акзапте, 1С пользователи дружно жмут Select * From ???? Достаточно жестко забитые программы, только отчетами и можно по моему баловаться а случись что разработчики за новый гонорар все подправят.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Так разговор на данном этапе даже не о записи а о чтении и расширенной организации данных. S>Да, я намеренно избегал говорить о записи. Там все начинает жить несколько по-другому. Скорость тут ни при чем, вопрос в том — не напоремся ли мы при использовании RID на необхдимость перезаписи ссылок? Как там с дефрагментацией удаленного дело обстоит?
Обычно как везде из удаленных записей организуется список И у каждой таблицы есть два поле FirstDeleted.
При удалени записи Record.Next:=FirstDeleted; FirstDeleted:=Record.RID. Понятно что размер записи не должен быть меньше 2 инта если нам хватает 2 милиарда записей. Проблема только при обмене данных и придется делать единый PK для обмена между базами получая все туже реляционность, но внутри базы использовать RID. S>>Вы Синклеером говорите что ООП на стороне сервера это тормоза, а я что нет и даже во многих случаях выигрышь. S>Нет, я этого нигде не говорил. Просто ты валишь в одну кучу совершенно не связанные между собой вещи. ООП не имеет никакого отношения к иерархическим базам данных; они, в свою очередь, не имеют никакого отношения к проблеме RID vs PK.
Это как бы две составляющие ООП имеет отношение к различным способам организации данных и легко к ним адаптируется. S>>А нужна прежде всего гибкость и скорость разработки а не за сколько выполнится тот или иной запрос. S>Вот второе высказывание с твоей стороны в этой беседе, c которым я могу согласиться. Ты в следующий раз так и начинай с разумных вещей, а не рассказывай про то, как двусвязные списки побеждают RDBMS Я все же не вполне согласен, в том смысле, что совсем отменить требования performance нельзя. Но важность скорости разработки, конечно же, рулит чем дальше, тем сильнее. S>>ECO, OBjectSpasec на сторону сервера!!!!! S>Итак, предлагаю закончить эту дискуссию на постулировании трех вещей:
S>1. Алгоритмы, применяемые в RDBMS, были разработаны для условий нехватки вычислительных мощностей и памяти S>2. Снижение стоимости памяти может сделать оправданным применение на низком уровне тех алгоритмов, которые ранее игнорировались в мире RDBMS S>3. Снижение стоимости вычислительных мощностей выдвигает на первый план скорость разработки систем, а не быстродействие при эксплуатации, что может сделать оправданным применение на низком уровне тех алгоритмов, которые ранее игнорировались в мире RDBMS.
S>Следующий виток — в новой ветке
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, avbochagov, Вы писали: A>Хорошо, не буду. Просто для примера: крупный магазин работал на системе аналогичной Cache несколько лет, размер все базы (бухгалтерия, склад, и т.д.) не превысил 700МБ — соотвественно сервер P3 266, 128МБ озу.
A>Сейчас систему сменили на 1с sql — купили сервер P4 2ГГЦ, 1ГБ озу, сокращение рабочих мест с 23 до 8, жалуются что медленно...
Аргументы про 1С против RDBMS не принимаются.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Я все же не вполне согласен, в том смысле, что совсем отменить требования performance нельзя. Но важность скорости разработки, конечно же, рулит чем дальше, тем сильнее. 
