Каморка

Кто-нибудь занимается разработкой приложений и баз для ASP (Application Service Providers)?

Рассмотрим два подхода.
1. Single DB for multiple customers.
Преимужества: простота администрирования. Других я не вижу.

Недостатки: В каждой таблице должен быть поле-номер клиента; все запросы имеют WHERE clientNo=number. Это головная боль для разработчкиов приложения и огромные возможности для ошибок (забыл WHERE - и получил чужие данные). Невозможно использовать security на уровне DB (сомневаюсь что security будет не на application level, но все-таки).


2. One DBMS, multiple databases; one DB per client.
Преимужества: Гибкость. С отдельной ДБ отдельного клиента можно творить что хошь.
Невозможно ошибочно получить чужие данные.
Производительность. Поиск по композитному ключу всегда будет медленнее поиска по single-field key.

Недостатки: Проще администрировать одну большую ДБ, чем 10 маленьких. Зато, например, бэкап 10 баз можно зафигачить в 10 разных мест.


Теперь самое интересное. Одно и то же приложение будет инсталлироваться по типу one hardware server per customer для крупных клиентов и one hardware server for multiple clients для мелких клиентов. По какому пути пойти? Для меня очевидны преимущества второго метода. Но есть сомневающиеся товарищи. Кто-нубудь что-нубудь может сказать в защиту первого подхода? Может я чего не понимаю? Повторю, что это не одна инсталяция одного приложения для нескольких клиентов, а несколько инсталяций. Но основная идея - иметь одно и то же (конфигурируемое) приложение для всех. А это значит - одна и та же структура DB для всех. А это значит что крупные клиенты будут использовать композитные ключи несмотря на то что они одни на своем сервере.

Что скажут ДБ гуру (или гуры?)


P.S. Вынужден убегать. Вы тут пофлеймите немножко, а я завтра к вам присоединюсь.

Всем заранее спасибо.

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

ЗЫ.... зовите работать, я вам нарисую как положено

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

много баз, для много клиентов, [trn] no odna baza dlya kazhdogo?[/trn]

папа Карло писал(а): ЗЫ.... зовите работать, я вам нарисую как положено

[trn]V Toronto? A ty poedesh' na mesyac?

Vse, sovsem ubezhal
[/trn]

StS писал(а):[trn] no odna baza dlya kazhdogo?[/trn]

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

А сколько клиентов? Если тысячи, то каждому базу....

А почему на view не сделать? Каждому юзеру свои вьюшки. Никто никуда не залезет. Но тоже не супер.

Я бы отделил уровень БД (как и логики, впрочем) на другой уровень со своим API. Для работы с ним надо открыть новую сессию, в которой id клиента будет создаваться автоматом и использоваться в работе этой сессии на стороне уровня БД. Разработчику не надо работать с id клиента, лишнее это. Т.е. что-то типа JAAS в Java: разработчик пишет, а админ конфигурирует.

Еще преимущества многих баз:
- восстановление из бекапа для отдельного пользователя незаметно для остальных.
- некоторые пользователи требуют пересылать им копии данных - очевидно, намного проще с индивидуальными базами.

Проблемы с администрированием при многих базах (10 это не много) решаются автоматизацией задач администрирования (скрипты) и/или использованием SQL Maintenance plans.

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

Еще преимущества многих баз:

В принципе, каждый acount можно рассматривать как отдельную БД: тебе же "пересылают" твой счет за телефон или банковские транзакции?

То же самое и с пользователями: каждый пользователь(клиент) - это на самом деле аккаунт. Зачем их бить на отдельные базы?

Я не администратор, поэтому на меня можно не ориентироваться, но как разработчик скажу: мне должно быть по-фигу как там лежат данные, если это не так - админа в Бобруйск

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

Я не администратор, поэтому на меня можно не ориентироваться

Я администратор, поэтому на меня можно ориентироваться

[trn]Esli ser'ezno... ja imel v vidu, chto, esli prilozhenie rabotaet v ASP modeli, ono, verojatno, rabotaet i otdel'no. V wtom sluchae nekotorye pol'zovateli trebujut kopiyu ih dannyh celikom - v vide polnoj bazy prilozhenija, chtoby ispol'zovat'[/trn] in-house [trn].

na samom dele nel'zja skazat' odnoznachno chto luchshe - ne hvataet detalej.[/trn]

зависит от требований всегда. и дизайн и имплементация.

STS и даже не думаи, только одна база данных.Один вопрос- база/ы данных будут на одном сервере или на разных?
И что значит "забыл WHERE condition"? И почему нельза security?
Представь себе ,sql server дожен будет "админить" несколко дб(инфо,system data) вместо однои дб. И backup db ты мозеш; зафигачить (copy) В 100 разных мест
Почитаи здесь ,много полезнои инфы( кстати етого паренька я знаю лично, и скажу тебе что он доволно грамматны спез)

Да, я база данных SQL Server
http://vyaskn.tripod.com/sql_server_adm ... .htm#Step1 --administaiting best practices
http://vyaskn.tripod.com/sql_server_sec ... ctices.htm --------security best practices

Юрий, ты уверен, что одна база это вай ту гоу? если так, что я скажу, что это _глубокое_ заблуждение. хотябы с точки зрения масштабируемости продукта и его ТСО ("стоимость на колеса")....

строительство подобной системы не начинается с "tips for dba"

ок,папа, обьясни мне почемю это заблуждение. И причем здесь типс for dba's. Я дал парню инфо почитать как to implement security ,that all

Yuri Dimant писал(а):ок,папа, обьясни мне почемю это заблуждение. И причем здесь типс for dba's. Я дал парню инфо почитать как to implement security ,that all

ок. предположим у тебя одна база. и сегодня у тебя 10000 пользователей. сколкьо будет стойть сервер и что в нем будет? теперь. завтра у тебя 20000 пользователей. внимание вопрос. насколько тебе надо увеличить производительность машины чтобы эти 20к пользователей работали с тойже производительностью что и первые 10к? когда все посчитаешь, посомтри тоже самое для 50 и 100к пользователей.

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

папа Карло писал(а):зависит от требований всегда. и дизайн и имплементация.

Конечно,
а иначе разговор ни о чем получается.

Иначе все похоже на дилентантизм. У новичков всегда так, попробовал что-то одно, получилось. Давай так всЁ буду делать! Ан не получится хорошо.