В продолжение моих изысканий методов построений SaaS, и опят несколько абстрактно...
Итак, надо сделать SaaS, предоставляющей клиентам что-то вроде специализированной CMS, и мечтательно предполагается, что клиентов будет десятки тысяч. У клиентов будет бд (MySQL, MariaDB или PostgreSQL), в которой хранится и собственно данные, и данные об интерфейсе работы с этими данными (включая дизайнерские особенности). Получается, у каждого клиента далеко не одна таблица, а, скажем, сотня, но при этом структуры и количество таблиц у всех клиентов одинаковые.
Как это сделать?
Можно создать одну бд, с мильеном таблиц, различающихся префиксом. Является ли минусом - бд с охрененным количеством таблиц?
Как любителю матрешек, мне бы хотелось, чтоб даже у одного клиента было несколько бд, как минимум, разрграничивающие интерфейс от самих данных.
Является ли минусом мильен бд, хоть и с небольшим количеством таблиц?

Прошу прощения за некоторую неточность формулировки вопроса, интересует в первую очередь механизм работы бд MySQL, MariaDB или PostgreSQL (насколько быстро и ресурсоемко) в случае одновременного обращения на сервер нескольких клиентов, когда:
a) на всех клиентов одна бд с мильеном таблиц;
б)  у каждого клиента своя бд (одна или несколько) со сравнительно небольшим кол-ом таблиц;
в) можно ли использовать для какой-то оптимизации то, что структуры таблиц в случае а) или бд (в случае б) абсолютно зеркальны у каждого клиента?

>  на всех клиентов одна бд с мильеном таблиц;

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

Хорошо это, или плохо - не знаю. Таблица-то одна, и это плюс, но есть и минусы (растет объем таблицы, может возникнуть вопрос с разграничением доступа к записям, усложняется работа с таблицей и т.п.). Это уж на месте виднее.

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

> KilkennyCat ©   (20.08.16 02:42) 

посмотри в сторону ORM, современные CMS все больше переходят на те или иные реализации этого подхода.

Я за вариант а)

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

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

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

> Игорь Шевченко ©   (20.08.16 10:13) [4]

тоже думаю о варианте a), хотя он мне не нравится, но ощущение, что он правильней.


> ухты ©   (20.08.16 11:20) [5]

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


> Юрий Зотов ©   (20.08.16 14:19) [6]

да, это третий вариант. тут вырастает количество записей в таблице.

Хранение в одной бд смущает еще тем, что физически это будет, грубо говоря, один файл.

> Хранение в одной бд смущает еще тем, что физически это будет,
>  грубо говоря, один файл.


А где здесь повод для смущения ?

> это будет, грубо говоря, один файл.

Который можно спереть...

> Игорь Шевченко ©   (20.08.16 15:10) [8]

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

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

> iop ©   (20.08.16 18:28) [11]

Выше я упоминал три варианта, MySQL, MariaDB или PostgreSQL. Возможно, имеет право на существование еще и MSSQL. Но точно не Парадокс.
И если мне не изменяет память, то у MySQL три файла - индексы, данные и инфо о структуре. MariaDB, вероятно, не сильно ушла в сторону. Про PostgreSQL и MSSQL не знаю.

какая вообще разница сколько там файлов, если с файлами работает сервер, а ты работаешь с объектами сервера?

у оракла всего одна бд на весь инстанс и минимум файлов
у мсскл несколько бд и минимум по два файла на бд.
у мускула полный аналог парадокса.

но нам-то што с этого?

> iop ©   (20.08.16 19:20) [13]
>
> но нам-то што с этого?

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

KilkennyCat ©   (20.08.16 20:03) [14]

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


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

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

> У меня нет опыта работы с большими и многоклиентскими решениями.


Глаза боятся, руки делают.
Насчет бекапа - в больших многоклиентских системах существует техническое обслуживание, во время которого на сайте вешается объявление - извините, у нас перерыв на такое-то время. Как вариант.
Насчет CMS - ты хочегь сделать что-то вроде аналога blogspot.com, если я тебя правильно понял ?

Если имеется раздробление на кусочки,

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

и нужно сделать alter table

берешь и делаешь.

а если в мускуле все на раздробленных кусочках,
то типа я возьму фар нажму ф4 и руками там побырому наалтерю таблицы?

> Игорь Шевченко ©   (20.08.16 21:46) [17]
>
> ты хочегь сделать что-то вроде аналога blogspot.
> com, если я тебя правильно понял ?

Примерно. Разница лишь в том, что у клиента уже может быть (и скорее всего) свой сайт и сервис будет инклюдом в него.


> iop ©   (20.08.16 21:54) [18]
> а если в мускуле все на раздробленных кусочках,
> то типа я возьму фар нажму ф4 и руками там побырому наалтерю
> таблицы?

Нет, зачем же. Создам некий инструмент администрирования, который будет, например, учитывать временную зону клиента, и какие-либо изменения для каждого клиента будут локальной ночью. Это в любом случае придется делать.
Чтобы сократить
> техническое обслуживание, во время которого на сайте вешается
> объявление