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

Я вижу несколько путей:

1. Использовать префикс фирм в существующих колонках идентификаторов id всех таблиц.
2. Добавить во все таблицы новую колонку "идентификатор фирмы" firm_id, по значению которой будет разделение.
3. Для каждой фирмы использовать отдельные таблицы, в именах которых будет присутствовать идентификатор фирмы.
4. Для каждой фирмы использовать отдельную базу данных.

У каждого решения есть свои плюсы и минусы. Посоветуйте какое выбрать? Может есть вариант получше?

или я отстал от жизни

(67) индекс и раньше был. Но добавилось еще несколько индексов и еще больше стало записей.

(63) (66) (68) ну щас потестирую.

(68) аналогично...когда даже пришлось отказаться от мускула пользу постгреса

6,066 total, Query took 0.0013 sec

(39) руками добавляешь во все базы? Циклом пробежаться по базам и сделать альтер табле? Смысл есть когда бизнес-логика в хранимках, если табле только для хранения данных - ловчее в отдельной базе. С другой стороны колонки можно заюзать и сделать шардинг ;) короч надо долго смотреть и думать.

составной использовался

(73)(75) эээ а на запись то?

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

(76) на запись медленнее, но это не так важно, я писал уже. Главное чтение.

(74) ок. Подумаю над размножением баз.

На скорость никак не повлияет если будет ~1000 баз на одном сервере?

+(73) проверил запрос на таблице 16М+ записей с составным индексом, тоже выполняется за время с двумя нулями после запятой.

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

(81) хм...
select count(*) from t1
--тут 10 000 000 000 записей
select * from t1
выполнится явно дольше...

(82) на сплошную выборку то пофиг, надо отбор делать по этому составному или пофиг что юзеры одной фирмы видят инфу всех?

(82) спасибо, капитан очевидность

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

(85) О, точно! Я что-то не подумал на счет того чтобы базу отдавать. Тогда отдельная база лучший вариант. И по скорости хороший.

Но вопрос, не замедлит ли сервер множество баз, остается открытым.

Замедление при большом количестве таблиц в одной базе я уже наблюдал: PHPMyAdmin просто зависал на выводе списка таблиц.

Если не предполагается делать отчётов по нескольким фирмам сразу, то - отдельные базы.
Нагрузка на сервер меньше всего будет в случае, когда в колонках префикс, также, в этом случае, не меняется структура базы, но все видят все данные.
Остальные решения можно считать костыльными, так как предполагают использование фильтрации на выборку данных, что на производительности сказывается не очень хорошо.

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

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

(87) >> Нагрузка на сервер меньше всего будет в случае, когда в колонках префикс

Меньше чем на отдельных базах? За счет чего разница происходит?

(87) на эту тему не дублирования данных сделать еще разделение на разные базы

есть общие справочники скажем в отдельной базе и есть отдельные базы фирм

Нет там никаких общих справочников. Писал в (0)

(88) В случае префикса у нас структура индексов не меняется, а в случае отдельной колонки добавляется ещё один индекс.
Отдельные таблицы и отдельные базы сильно увеличивают место под хранение данных.

Отдельные базы - самый удачный случай - так как работа будет идти полностью независимо - распределяться будет только память и процессорное время.

(91) предлагаю отдельные сервера и не ..ать мозги

(92) Ещё скажи территориально разнесённые.

(0) сам же говоришь, что данные ни как не связаны, так на кой кол их в одной БД-то держать?

счас запутаю :)

для каждой фирмы использовать отдельного SQL юзера и рулить правами :)

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

(95) муахаха

ЗЫ представил права на отдельную запись ...

(0) "Король Умер, да здравствует король" (с)

(94) как на кой? На каждую новую базу уходят дополнительные ресурсы сервера! Даже абсолютно пустая база требует некоторых ресурсов.

(99) Бред... SQL Только для пустой БД отъедает 6 Гб
Дольше идет накопление информации.

Справочники тоже не так много кушают.


...
Вам жалко 6 Гб?
Тогда страдайте головными болями :)

(100)  Сервер то не мой, а в облаке. Там за каждый Гб денег хотят. Нужно максимально сэкономить при одинаковой производительности, для получения максимальной прибыли.

(101) Кто их туда поместить порекомендовал? Коль у них денег на такое нет :)

Тогда что ты нам тут мозг пудришь?
Берешь свою "Нетленку" и допиливаешь, её до ведения учета по нескольким фирмам.
Преждевременно выставляя счет на сей модинг.

И наблюдай, как у заказчика найдутся деньги, стулья и другие вещи для размещения второй БД в Облачке :)

меня вот другое смущает

>>>Данные разных фирм между собой никак не связаны.

вот не верю я в это, например курс валют, или контрагенты....

(102) деньги то есть, но отдавать их не хочется если можно не отдавать.

(103) Вот делать мне больше нечего, искать совпадающие элементы справочников у разных фирм, которые могут совпасть по названию или по url сайта или по адресу, или по номеру телефона, а могут и не совпасть если у одного элемента урл http://dsgds.ru, а у другого http://www.dsgds.ru/?hru=254686, или адрес по разному записан, или телефон у одного 223-322, а у другого 22-33-22, бывает еще с кодом города и без, или вообще с ошибками. Встречал урл вида: Http;/http://www.dsgds.ru

Совпадения между двумя фирмами отыскиваются в 10% элементов справочника, где 5% правильно совпали, а 5% ошибочно.

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

(105) тогда это разные базы...

(105) Блин, движок форума испоганил УРЛы. в последних двух я не писал http://

(106) похоже у разных баз нет преимущества по скорости перед префиксами у id?

(108) у разных баз есть одно немаловажное преимущество...

тебя потом не так сильно пинать будут, и может даже плюнут искать...

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

а вообще почитай профильную литературу, ибо у тебя каша в голове сейчас...

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

Никаких плюсов по скорости нет по сравнению с префиксами?

(104) Деньги всегда придется отдать. Если только ты все это сделаешь сам и бесплатно :)

(112) Вопрос не в деньгах, а в скорости. По теме есть мысли?

(111) Тебе сказали про статистику запросов и предложили почитать профильную литературу. Ты пропустил это мимо ушей и продолжаешь снова и снова задавать тот же вопрос.

(113) О какой скорости идет вообще речь.
любой вариант  1-3 это как минимум переписывание всех отчетов по этим базам с отладкой с ошибками с заложеными граблями и.т.д. и отвечать за это придеться уже тебе.

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

(114) Я спрашивал что мне почитать?
Если не могут ответить на мой вопрос, буду ждать того кто сможет.
Ответы на не мой вопрос буду пропускать или выборочно комментировать.

(115) О скорости работы SQL сервера. Про переписывание отчетов вопрос не стоит.
Как дублирование может замедлить одну базу в отличии от разных баз?

(117)
Нет такого понятия скорость работы sql сервера.
Даже один и тот же sql запрос может формировать одни и те же данные разное время в зависимости от множества причин.


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

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

если у всех фирм НСИ примерно одинакова (например таблицы с контрагентами, продукцие...), либо база требует частого одновления-администрирования - лучше (2) новая колонка в таблицах + изменение индексов + доработка отчетности

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

(116) спрашивал чего почитать?

http://www.williamspublishing.com/Books/DG_DBA_SQL_SRV_2000.html (только для своей версии)

что-то из подобного
http://www.iso27000.ru/chitalnyi-zai/setevaya-bezopasnost/bezopasnost-v-setyah-hraneniya-dannyh
http://compress.ru/article.aspx?id=18048
(касаемо раздельного доступа к данным и обеспечения SLA)

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

на сим раскланиваюсь и удаляюсь

"Ты мне не интересен" (с) Волшебник, Обыкновенное чудо...

>> Вам аргументировано возражают, что правильно будет по другому

Я написал что мне нужно, а мне навязывают то что мне не нужно.
Мне же виднее какие у меня требования  к задаче.
Я спрашиваю как уменьшить нагрузку на сервер, а мне про какие-то переписывания логики отчетов рассказывают. С чего вы взяли что существуют эти отчеты? Их нет. Ни сводных, ни раздельных.
Так же про дублирование клиентов. Их нет.
Не нужно делать аналогию с 1С. Это совершенно другая база.

Тогда самый главный вопрос - как происходит подключение к базам, и насколько серверная часть "помнит" каждого клиента.
Просто, если окажется, что система написана на Web-сервисах, то использование различных баз может быть просто невозможно, если система в кеше хранит только соединение к последней базе, так как будут просто сплошные пересоединения, что съест рабочее время.
Опять же, например SQL-сервер FireBird поддерживает до 16 баз в одной транзакции, а больше 16 - извините, уже придётся выбирать отдельно.

Так что - ответ на ваш вопрос без специфики задачи просто невозможен.

SQL-сервер хотя бы какой будет ?

(122) Писал уже выше. Сервер - MySQL. Клиент подсоединился, получил данные максимум за 0.01 секунды, отсоединился. В каждую фирму клиенты могут подсоединяться раз в секунду. Так как сейчас около 700 фирм, то получается 700 раз в секунду по соединению в общем. В итоге процессор загружен больше 100%, клиенты висят в очереди ожидания.

(123) Тогда разделение по базам вас не спасёт, если только не будет стоять предсервер, который запросы разных фирм будет в разные базы отправлять.
В случае MySql и особенно текстового хранения таблиц лучше всего разделять именно таблицами. Хотя, последние версии MySql даже с транзакциями работать умеют.

А от очереди избавится не получится - если порт слушать, в общем случае, могут несколько процессов и каждый по очереди получает себе запрос на обработку. Если база одна, то ему переподключаться не надо - он может начать работать. Конечно, придётся делать выборку каких-то таблиц, но это процесс не сложный, тем более, что кеширование данных таблиц никого не спасёт.
Префиксы и прочие "ухищрения" заставят процессы лезть в одну общую таблицу, что на производительности скажется отрицательно.

(123) мда, 700 коннектов в секунду...положат сервак влегкую...причем любой

вообщем в вашем извращенном случае, решение это:

разные сервера!

несколько мускулов запускаешь с разными портами (на одном сервере, тока оперативки побольше), далее "предсервер" точнее в php выбирается к какому обращаться

(127)+ и самые затратные операции это коннект/дисконнект...

так что держи на php постоянный пул коннектов и юзай их для обслуживания очереди запросов ))

Аудитор фирмы 1 попросит базу для анализа. Как отдать, если в базе несколько фирм?

1cfresh.ru колонка область данных

(128) MySQL разве сам не кеширует коннекты? Я конечно могу держать постоянно открытый коннект и использовать его для разных клиентов. Но нужно-ли это делать?

(129) Можно его нахер послать по причине что в базе несколько фирм.

(132) Нельзя его послать :)

+(132) Послать та можешь, но тот орган, который требует Аудита будет в дальнейшем только рад такому обстоятельству :)

ты-бы хоть для приличия текст запроса дал....

вообще на 700 коннектов в секунду делают ХП в качестве параметра у нее имя клиента и его пароль в рамках одной сессии (можно в рамках десяти сесий)...

это
1. сократит трафик самих запросов
2. сократит авторизацию (не требуется ответ сервера)
3. упростит отладку и исправление
4. закроет прямой доступ к данным, будет работать по принципу RLS от 1с

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

(133) Можно. Кто он такой? Я его не звал.

(134) Никто не потребует аудита моей базы. Там нет ничего интересного для них.

(137) А нам тут то не видно, что вы там ведете.
Если только Управленческий учет, а Бухия у этих фирм отдельно. То тогда Аудита не будет.
Иначе, вы просто не дальновидный человек :)

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

адская интернет сеть магазинов ..

(140) Поменьше чем у Яндекса. На много.

(139) неужто систему еЗаказа ваяешь?

(142) не знаю о чем ты.

(143) ну от поставщика к покупателям прайсы, а от покупателей к поставщику заказы

(99) А ты не озвучил плюсы и минусы перечисленных тобой в (0) вариантов.

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

(140) вообще то похоже на посекундный билинг...

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

билинг штука тонкая...

(147) Просто в России "коленочное производство" продвигается во все области деятельности. Поэтому, даже сложные и надёжные системы могут писать те, кто научился программировать на BASIC-е или около того.

(144) типа того.

(148) не только, я еще на турбо паскале научился программировать.

(150) Молодец.
Только, в данном случае, более уместно знание хотя бы php.
Хотя, на паскале тоже можно Web-сервер наваять.

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

(151) Возвращаемся к вопросу, кэширует ли MySQL подключение или нет?

У меня сейчас веб сервер постоянно держит соединение с MySQL сервером. Сколько процессов веб сервера запущено, столько и подключений. Обычно 5 штук. Но никакой прибавки скорости не заметил по сравнению с тем когда для каждого клиента происходило новое подключение.
Почему так?

(153) не твоя любимая одежда?
http://s.pikabu.ru/post_img/2013/07/30/10/1375198251_187774581.jpg

(153) Если еЗаказ и зная что статика быстрее:

1. Выкидываем прайсы из базы в файлы и юзверям отдаем статические готовые страницы
-минус нагрузка на базу сразу

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

3. Самому то слабо было придумать? Лисапед древний как ... от мамонта

(154) Нет, больше на твою похожа.

(155) Блин, как я сам до этого не догадался?! Жаль что оно мне не нужно.
По теме еще будут полезные сообщения?

(154) Да его это, ник уже о многом говорит :)

(157) Только стеб... ибо уже ответили, насоветовали... А воз и по сей день там :)

(159) Посоветовали, но это был не ты.

Сегодня не связаны, завтра фиг его знает. Я за новую колонку, это универсальнее.

(160) Скажи хоть, что ты решил делать?
Какие квадратные колеса в ведении учета и в экономии на спичках :)

(161) Ага, человек хочет экономить на Объемах информации, а вы ему новую колонку. Где тут экономия? :)

(163) Бред. Не ври что я хочу. Тебе это не известно.

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

(165) а это уже по желанию

ЗЫ А что еще не всЁ поделили?

И вообще нафига им какой то сервер с 700 клиентами в секунду

сформировать прайс в экселе и разослать по мылу... ответные прайсы-с-набитыми-колвами-заказы спец.тренированная обезъянка будет грузить в базу...

во все как у Сохранение прайс-листа из 1С в эксель требуемого формата.

>>Данные разных фирм между собой никак не связаны.

В этом есть большие сомнения...
Также нужно подумать над тем как получать консолидированную отчетность если таковая нужна.