Одна база данных, несколько клиентов

Question

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

Это все очень хорошо.

Однако, допустим, у нас есть таблица Ticket. Идея имеет первичный ключ. Когда пользователь добавляет билет, он будет соответствовать клиенту через внешний ключ и т. Д.

Однако для каждого клиента я хочу, чтобы его идентификаторы билетов начинались с 1 при регистрации.

т.е. клиент 1 добавляет 4 билета, количество ticket_id будет равно 4. Клиент 2 зарегистрируется, они добавляют билет, а затем ticket_id будет 5 и так далее, и так далее. Что не идеально.

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

Надеюсь, это имеет смысл, и я с нетерпением жду ваших отзывов.

РЕДАКТИРОВАТЬ: помечены как symfony, поскольку я буду использовать Doctrine ORM в symfony для управления базой данных ... возможно, это не имеет значения, но добавлено на всякий случай.

РЕДАКТИРОВАТЬ: Я также мог бы быть глупым и упустить что-то очевидное здесь, поэтому мои извинения.

Answer 1

Почему бы просто не добавить столбец ticket_num и самостоятельно управлять их последовательным идентификатором?Если вы используете доктрину, обратите внимание на реализацию метода preInsert в вашей модели Ticket.

Answer 2

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

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

Answer 3

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

В этом случае клиентвидит номер билета как 2010062407 и думает: «ясно, что это связано со днем, может быть, даже со временем».Но я не думаю, что клиент скажет: «Как я набрал 2 миллиарда билетов на проблемы ?!»

Answer 4

Должен ли я понимать, что каждому клиенту будут перечислены свои билеты последовательно от 1 года?Я предполагаю, что у каждого клиента есть свои билеты, и они не выставляются другим клиентам.Вы должны уточнить это в своем вопросе.

Я бы предложил создать новый столбец в вашей таблице заявок для использования в качестве ссылочного номера (назовем его ref_num).Когда клиент 2 создает заявку, то ticket_id будет равен 5, но ваше приложение будет знать, как присвоить ref_num значение 1 для этого пользователя.

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

К вашему сведению, здесь мы не беспокоимся о сокрытии информации от пользователя,Мы используем поле ref_num, чтобы скрыть истинные идентификационные номера от пользователей.У нас есть несколько отделов, в каждом из которых есть несколько клиентов, которые используют один и тот же пул ID.Если группа A создает билет 23456, тогда группа B создает другой билет, он выглядит как 23457, несмотря на то, что предыдущий билет не принадлежал им.Номер билета не обязательно должен быть последовательным.

Answer 5

Я бы сказал, что вы должны оставить основной идентификатор таким, какой он есть, логически он должен быть внутренним.Вы можете сгенерировать уникальный идентификатор (GUID, метку времени) и использовать его для отображения.В качестве альтернативы вы можете сгенерировать уникальный идентификатор (для целей отображения), объединяющий сначала, скажем, 4, буквы имени клиента, а затем добавьте его с нулями.

что-то вроде:

APPL000006

GOOG000004

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

Answer 6

Создайте новую таблицу с именем CustomerTickets, в которой есть два столбца: идентификатор клиента и идентификатор билета. Чтобы ваш клиент прочитал последний идентификатор билета из таблицы для вашего идентификатора клиента, увеличьте его, а затем запишите его в свою фактическую таблицу заявок, свернутую в транзакции.

Answer 7

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

tickets_1 //all tickets for customer with id 1
tickets_3 //all tickets for customer with id 3

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