Одну на всех.
А можно поинтересоваться? что за сервер? Какая нагрузка, объем данных?
Posted via ActualForum NNTP Server 1.3

Yaral wrote:
> Вот все спрашивают "что за сервер? Какая нагрузка, объем данных?" а
> какая разница?
да большая, собссно...
потому как ежели, скажем, у вас 5 счетов в день - то вам глубоко по
шарабану, как и на чем делать.... Лишь бы AV или SF не летели...

Если средние размеры - тут возможны варианты...
Если большие... Ну.... начиная от того, что таки да - по табличке на
оператора, заканчивая партиционированием, архивированием и прочей
лабудой, подведением субитогов, закрытием опердня (или чо там?) и т.д.
От сервака, опять таки, зависит... Тот же орацл держит
партиционирование, юкон - тоже, а ASE - нет...
Орацл можно поставить "раком", а МС СКЛ - "зафедерить".
Сайбейз - побить операторов на инстансы и реплицировать сводки на
главный инстанс....

в общим, вариантов - масса... а вот такое "как мне сделать "взагали""...
Есть токо один ответ: НИКАК.

зы спс за внимание.

Posted via ActualForum NNTP Server 1.3

Yaral wrote:
> Хорошо, давайте так:
> Если размер БД небольшой то можно писать на чем угодно и как угодно?
> Помоему нет.
По моему - да. Ибо - требования к перформансу у сельской телефонной
станции - более чем скромные, нес па?
> Если средний? Помоему никак не отличается от небольшого.
Отличается. "село - ПГТ".
> Ну а если большой размер... а что в настоящее время такой размер? Это
> сколько? 70 GB чтоли? Или 200 GB?
Или 400... или 1400... ничего ж не сказано о том - что, где и как, ага?

> И это влияет на "На каждого оператора по таблице или все платежи в одной
> таблице?"
Да, и это - влияет... увы....

> Или количество пользователей системы влияет на это? Может для
И это тоже влияет....

> пользователя для каждого по табличке создавать тогда?
И такое бывает тоже.....
Posted via ActualForum NNTP Server 1.3

Yaral wrote:
> Ну как влияет то не слова... а без этого это просто пустые слова
Пока не конкретных ТУ можно высказывать только общие предположения.
ТУ нет - следовательно разброс мнений от "делай так" до "делай вот эдак".

Если есть конкретные сомнения по каким-либо пунктам - милости просим в
студию.
Posted via ActualForum NNTP Server 1.3

Yaral wrote:
> Дребований действительно нет. Но на счет размера, чем с большими по
> размеру БД мне доводилось работать, тем с более я понимал что
> нормализация данных это не пустые слова. И по этому странно читать что
> даже бывает и на каждого польсователя совою таблицу делать, помоему если
> такое случается то это признак изночально плохо спроектированной системы.
> Да и объем данных в ГБ это не показатель, при нормализации и правильной
> расстановке индексов размер таких баз уменьшался в десятки а бывало
> сотни раз. Соответсвенно и скорость работы.
> А то что нагрузка влияет на нормализацию это вообще оригинально.
> Так что я считаю что вопрос о сервере и нагрузке на БД здесь не совсем
> уместный, в первую очередь нормализация данных.

Почитайте книги, в который говорится о "денормализации" - узнаете для
себя много нового.... Когда за счет "излишнего" дискового пространства
выигрываем по скорости....

Заодно услышите такую фразу, когда "Урод эксперимент убил красавицу
теорию" :-).

кроме обычной работы существует также обслуживание базы, которое,
зачастую, удобнее и "рачительнее" проводить по 10-ти небольшим объектам,
чем по одному большому... и т.д. и т.п.

Опять таки - какой сервер? У разных серверов - разные возможности, и,
следовательно - разные технологические решения. Я уже писал - тот же
Юкон умеет отсоединять часть таблицы (а значит проблема архивирования
может решаться одним путем), а тот же сайбейз - не умеет... Тот же оракл
умеет делать кластера по перформансу, а тот же юкон - только по
надежности.... и значит у оракла возможен scale-out, а у юкона (вообще
говоря) - только scale-up....
Posted via ActualForum NNTP Server 1.3

Yaral wrote:
> Про денормализацию я как раз читал, но в любой книге написанно, что
> денормализацию следует проводить после нормализации, а не до и не
> вместо. И денормализация проводиться по определенный методам и правилам.
Никто и не сомневался.

> И я не думаю что после ее применения одна таблица с платежами разобъется
> на несколько по признаку оператора. В основном денормализация касатся
> переноса полей между главной и подчиненной таблицами.
А вот это вы зря. Абсолютно зря. Очень даже может разбится. Конечно,
"зависит от"... От ТУ, хотел сказать. Но могу навскидку придумать пару
полуреальных примеров, когда такое разбиение (полное или частичное) было
бы оправдано.
Posted via ActualForum NNTP Server 1.3

Yaral wrote:
> Интересно было бы вглянуть на такой пример

К примеру, мы можем иметь ситуацию, когда информация по платежам для
каждого из операторов довольно сильно отличается, вплоть до крайнего
случая, когда между ними общего - только лицевой счет, сумма, дата и
номер квитанции, а прочая требуха - типа внутреннего номера транзакции и
проч. - разное.
В этом случае может быть выгодно вынесение общей части (лицевой, сумма,
номер, дата) в одну общую таблицу (дабы потом было удобно работать), а
специфическую информацию - в табличку, характерную для конкретного
оператора, связанную с общей табличкой "один к одному".
Еще более крайней ситуацией является, к примеру, вариант, когда на
основании платежа оператора просто изменяется баланс лицевого счета и не
строятся общие оборотные ведомости по всем операторам. в этом случае нам
вполне допустимо завести по табличке на каждого оператора. Плюсы и
минусы каждого решения можно оценить только после получения более
детальных требований.
Posted via ActualForum NNTP Server 1.3

Yaral wrote:
> "когда информация по платежам для каждого из операторов довольно сильно
> отличается" - Это получается что вместо анализа этой информации, т.е.
> какие вообще могут быть таблици, атрибуты, и связи в этой предметной
> облости т.е. без проектирования, мы просто делаем по таблице для каждого
> оператора... а потом добавляется еще один оператор и что? Еще таблицу? А
> потом если еже денормализации все это подвергнуть! А что будет с
> клиентскими приложениями?...
не "вместо" а "вместе и после" и "по итогам полевых испытаний".
И, наверное, не "на каждого оператора" а "на каждую группу операторов".
Кроме того надо учитывать случаи когда красотой логической теории
жертвуют на потребу реальным условиям/возможностям серверов (о которых,
кстати - ни слуху ни духу).

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

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

зы на текущий момент мы скатываемся к обсуждению "сферического коня в
вакууме", с аргументами "конь должен быть не сферический, а
эллиптический, на крайний случай - тороидальный". Без конкретных условий
для задачи - занятие увлекательное, но непрактичное.
для проформы можно завести "холивар" "Один против многих". Но смысла
вроде бы нет.
Posted via ActualForum NNTP Server 1.3