Multiple DBs vs One DB

[Yuri Dimant]

Папа, все что ты привел, есть за и против.Какая разница если все ети базу быдут на одном сервере , есть смысл в несколких базах на remote сервер ,но ето уже пахнет replication или нужен скрипт на синхронизаю между базами данных, а это головная боль.
Я имею саит с 30К пользователеи и однои VLDB и никаких проблем.

[vg]

Папа, все что ты привел, есть за и против.Какая разница если все ети базу быдут на одном сервере , есть смысл в несколких базах на remote сервер ,но ето уже пахнет replication или нужен скрипт на синхронизаю между базами данных, а это головная боль.
Я имею саит с 30К пользователеи и однои VLDB и никаких проблем.

Согласен с мнением. На нашем опыте несколько баз + последующая синхронизация с основной базой прокатывает если:

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

- обновление "справочной информации" из основной базы (положим, БИКи, на Российском опыте, или другая инфа классификаторов) - не частое (раз в декаду)

Так работали базы некоторых министерств и банков в России со своими отделениями.

[StS]

Я имею саит с 30К пользователеи и однои VLDB и никаких проблем.

[trn]Wto ne argument. Ty putaesh' konechnyh pol'zovatelej i nashih klientov. Pochitaj esche raz moj pervyj post. U kazhdogo nashego klienta est' svoi pol'zovateli. Voz'mem primer s telefonnym bilom. Dopustim, est' prilozhenie dlya telefonnoj kompanii. Esli wto Bell, to emu stavitsya otdel'nyj server. Esli wto melkaya kompaniya, to prilozhenie i baza mozhet zhit' na tom zhe servere gde zhivut prilozheniya i bazy drugih melkih telefonnyh kompanij.[/trn] DBMS [trn]na servere - odna.[/trn]

И почему нельза security?

[trn]Nel'zya sekjuriti na urovne BD. Potomu chto esli odin nash klient (ne putat' s konechnymi pol'zovatelyami) reshit chto[/trn] human resource[trn] mozhet posmotret' [/trn]SIN[trn] rabotnika, a drugoj ne zahochet wtogo, to v odnoj baze ne dash' dostup k polju na osnovanii znacheniya drugogo polya. Ili sejchas BD wto umejut?[/trn]

на самом деле нельзя сказать однозначно что лучше - не хватает деталей.

[trn]Kakih detalej ne hvataet? Davaj dam detali.[/trn]

[dima]

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

1. я согласен. Нельзя-ли обьеденить клиентские id в группы, штук так по 1000 в каждую и на каждую группу выделять базу.

2. Если бизнес-логика позволяет, то всю SQL-щину неплохо вынести на сторону базы данных в stored procedures (для записи в таблицы) и views (для чтения). В таком случае не надо беспокоится о том, что кто-то where clause не написал правильно.

Опять-же если бизнес-логика позволяет.

Еще один недостаток с огромными таблицами - performance.

[StS]

Согласен с мнением. На нашем опыте несколько баз + последующая синхронизация с основной базой прокатывает если:

[trn]Net nikakoj sinhronizacii. Bazy nezavisimye. Narod, ya chto-to neyasno izlagaju?[/trn] Application Service Provider [trn]hostit prilozhenie dlya melkih i krupnyh klientov. Prilozhenie odno, no konfiguriruemoe. Ne dumaju chto mozhno bez gemoroya zakonfigurit' prilozhenie tak, chtoby dlya raznyh klientov byla raznaya struktura DB. Dlya melkih klientov est' rezon derzhat' neskol'ko prilozhenij na odnoj zhelezyake. Vopros: odna BD s razdeleniem po klientam na urovne prilozheniya ili dlya kazhdogo klienta svoya DB, kotoraya v sluchae s melkimi klientami delit[/trn] DBMS[trn] s bazami drigih melkih klientov.[/trn]

[BB]

[trn]Naprimer:
- ispol'zuetsja li [/trn]stand-alone (not ASP) [trn]versija
- dopuskaetsja li (sejchas ili v budushem) nastrojka bazy pod konkretnogo klienta (dopolnitel'nye polja, [/trn]custom [trn]spravochniki, i t.d.)
- kto i kak budet delat' otchety? Mogut li klienty zakazyvat' i razrabatyvat' svoi otchety i potom hostit' na vashem ASP.
- kakie trebovanija po [/trn]availability[trn]?

V obshem, v [/trn]ASP [trn]klient polagaet, chto s prilozheniem rabotajut tol'ko ego pol'zovateli i ego dannye prinadlezhat emu. So vsemi vytekajushimi... [/trn]Keep that in mind.

[папа Карло]

Папа, все что ты привел, есть за и против.Какая разница если все ети базу быдут на одном сервере , есть смысл в несколких базах на remote сервер ,но ето уже пахнет replication или нужен скрипт на синхронизаю между базами данных, а это головная боль.
Я имею саит с 30К пользователеи и однои VLDB и никаких проблем.

можно построить так что не репликации ни синхронизакции не надо будет. у тебя сайт с 30к пользователей, которые хранят свои данные на нем? сколько процов в сервере БД? сколько надо будет ресурсов для поддержки твоей системы и 50к пользователей?

[StS]

[trn]Naprimer:
- ispol'zuetsja li [/trn]stand-alone (not ASP) [trn]versija[/trn]

[trn]Da[/trn]

[trn]- dopuskaetsja li (sejchas ili v budushem) nastrojka bazy pod konkretnogo klienta (dopolnitel'nye polja, [/trn]custom [trn]spravochniki, i t.d.)[/trn]

[trn]Net. Esli klient chto-to hochet i my reshaem wto implementirovat', to wtu funkcional'nost' poluchajut vse. A budut li oni ee ispol'zovat' - ih delo.[/trn]

[trn]- kto i kak budet delat' otchety? Mogut li klienty zakazyvat' i razrabatyvat' svoi otchety i potom hostit' na vashem[/trn] ASP.

[trn]Otchety kak chast' prilozheniya? Ih delajut klienty. Sistemnye otchety tipa kolichestvo unikal'nyh pol'zovatelej? Skoree vsego chto my, no pri krupnom kliente mozhno najti gramotnogo cheloveka i spihnut' wto na nego.
Chto znachit "hostit' otchety"? Delat' ih dostupnymi konechnym pol'zovatelyam? Da, no wto chast' prilozheniya (ili otdel'noe prilozhenie).[/trn]

[trn]- kakie trebovanija po [/trn]availability?

[trn]Vysokie. No razve wto vopros DB?[/trn]

[trn]V obshem, v [/trn]ASP [trn]klient polagaet, chto s prilozheniem rabotajut tol'ko ego pol'zovateli i ego dannye prinadlezhat emu. So vsemi vytekajushimi... [/trn]Keep that in mind.

[trn]Ya dumaju on takzhe polagaet chto i s dannymi rabotajut tol'ko ego pol'zovateli. Wto esche odin argument v pol'zu [/trn] one DB per client.

[Zy]

Это есче один аргумент в пользу one DB per client.

Сколько пользователей/клиентов предполагается обслуживать через пять лет?

[StS]

Сколько пользователей/клиентов предполагается обслуживать через пять лет?

[trn]A kakaya raznica? Dopustim, 100 klientov sejchas, iz nih 80 melkih. U kazhdogo ot 500 do 5000 pol'zovatelej. Dopustim, cifry udvaivajutsya. I chto? Esli zhelezyaka ne potyanet 160 klientov, perekinem 80 na druguju zhelezyaku. Ne vazhno kogda wto proizojdet - cherez 5 let ili v sledujuщem godu. Pri razdel'nyh DB wto proщe.[/trn]

[Zy]

А какая разница?

Мммм... Ну, я не знаю... Просто перед тем, как что-то делать, составляют некий бизнес-план. Так сказать - где бабки? Если деньги не считаются, то это благотворительный фонд или еще какая общественная/государственная организация, тут у меня опыта нет.

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

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

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

[Marmot]

А вот у Оракла есть такая штука, называется Virtual Private Database
Для данного случая - самое то.
Я бы сделал систему many-to-many, так сказать, несколько серваков с несколькими клиентами, на каждом серваке VPD.

[Yuri Dimant]

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

Теперь, да, я храню инфо о каждом (30к) клиенте у себя в бд с 8 процесоров, длаьше лесть в дебри нашеи имплементации нет смысла (заимет еше куча времени) но правильно спланирована дб, индехсы позволяет нам получать слозные репорты в считанные секунды.

[Yuri Dimant]

>Нельзя секюрити на уровне БД. Потому что если один наш клиент (не >путать с конечными пользователями) решит что human resource >может посмотреть SIN работника, а другой не захочет этого, то в >одной базе не дашь доступ к полю на основании значения другого >поля. Или сейчас БД это умеют?

http://vyaskn.tripod.com/sql_server_sec ... ctices.htm --------security best practices

[Zy]

у его клиентов есть есть другие клиенты

Он говорил о пользователях и клиентах.