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

> Kerk ©   (20.08.16 23:23) [20]

Вот... если уж ты по уши, то мне ваще кранты :)

все эти заморочки с выбором по файлам странны.

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

> iop ©   (21.08.16 00:09) [22]
>
> все эти заморочки с выбором по файлам странны.
>
> клиент заказывает такси,
> диспетчер ему говорит, что есть новый опель, старый мерс
> и трехлетняя приора.
> а клиент заморочен скольки клаппаный движок в каждой.

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

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

> KilkennyCat ©   (21.08.16 00:59) [24]

<OFFTOP>
Уж как мне всё это до боли знакомо. :)
</OFFTOP>

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

Клапана-то здесь причем?
Ни таксопарк ни водила не даст клиенту воспользоваться заказанной услугой на уровне клапанов движка.
Будь клиент хоть механиком мотористом восьмидесятого уровня.

> iop ©   (21.08.16 12:11) [26]
>
> Ничего странного. Клиент озабочен тем, чтобы он достиг нужной
> точки в нужное время.
>
> Клапана-то здесь причем?

А при том что "клиент озабочен"! И при том что клиент не верит на слово диспетчеру.
Тут с одной стороны прав ИШ, когда говорит
> Глаза боятся, руки делают

а с другой стороны надо с чего-то начинать делать. А с чего именно непонятно.

>  надо с чего-то начинать делать. А с чего именно непонятно.
с чего всегда, с постановки задачи, так думается )

Перечитал первый пост. Ну дак база на сервере же? И структура не различается у клиентов. Тогда разумнее одна БД на всех а в БД  одна структура на всех. Вроде бы целый mail.ru работает на MySQL и я сильно сомневаюсь что у них там на каждого из 30 миллионов клиентов что-то отдельно создаётся, кроме как, добавление клиента в таблицу "список клиентов" с присвоением ему ID.

> KilkennyCat ©   (20.08.16 20:03) [14]
> привычка понимать механику всего, учитывая, что весь проект
> мне делать в одиночку, полностью, начиная с установки сервера
> и заканчивая его поддержкой. хочется заранее понять и спрогнозировать
> возникновение хотя бы основных подводных камней.

"Подводные камни" - в администрировании БД и её тюнинге правильными индексами, если количество записей в таблицах будет большим.
Сколько там файлов - никого не парит вообще.

Кстати, ЮЗ назвал весьма верный критерий при выборе: разграничение прав готовыми средствами сервера БД.
Как правило, сервера БД элементарно (т.е. встроенными средствами) позволяют разграничить доступ разным пользователям к разным таблицам или разным БД в рамках одного сервера.
А вот разграничить доступ на уровне записей в одной таблице готовыми средствами администрирования - вроде где-то слышал, но это точно не типичная задача, поддерживаемая большинством серверов. (чтобы другой пользователь не получил чужие даные, не изменил чужие данные намеренно или из-за ошибки в твоём ПО.) Т.е. в этом случае придётся разграничивать уже в своём приложении (или самописных хранимых процедурах), а это время на написание, отладку, риск собственных ошибок при развитии приложения и, как следствие, несанкционированный доступ к данным или их изменение.

Если это вообще критично для задачи - то стоит про это подумать. Если не критично - то пофик, валить однотипные данные клиентов в одни и те же таблицы, разделяя по user_id.

А вот разграничить доступ на уровне записей в одной таблице .....

над этим можно думать когда пилишь обычную двузвенку.

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

так что про эту фичу в этом конкретном случае можно тоже не париться.

>KilkennyCat
FYI:

http://dataconomy.com/sql-vs-nosql-need-know/
https://www.oreilly.com/ideas/data-modeling-with-multi-model-databases

Другая неплохая статья:
https://www.mongodb.com/nosql-explained

>Является ли минусом мильен бд, хоть и с небольшим количеством таблиц?
Мое мнение: не является.
Но на мой взгляд, логичнее и удобнее в поддержке иметь одну БД Production на клиента (естественно, можно создать еще и несколько других подобных БД (тест, пред-production, etc))

Performance.
Достигается другими путями ежели в SQL DB, особенно учитывая легкость в "горизонтальном" наращивании мощностей.

ПС. Для выполнения моих задач, я остановился на ArangoDB.
http://vschart.com/compare/arangodb/vs/mongodb

> Empleado ©

спасибо.