Остаток от деления

Всем привет!
Возникла небольшая проблема. есть перечень услуг, например:
ID Name
1. Услуга 1 физ лица ( деятельность 1)
2. Услуга 2 физ лица ( деятельность 2)
3. Услуга 3 физ лица ( деятельность 3)
4. Услуга 4 физ лица ( деятельность 4)

5. Услуга 1 юр лица ( деятельность 1)
6. Услуга 2 юр лица ( деятельность 2)
7. Услуга 3 юр лица ( деятельность 3)
8. Услуга 4 юр лица ( деятельность 4)

Принадлежность услуги к деятельности определялась путем остатка от деления % 4 ( во многих вьюхах и процедурах). Полученный результат вносился в качестве ключа в таблицы, связанные с деятельностью. Например, если в произвольную таблицу, содержащей связку-договор по "Услуга 3 юр лица" необходимо использовать id деятельности- то:
7%4 = 3. т.е. id деятельности = 3

Проблема:
необходимо добавить еще пару услуг:
9. Услуга 5 физ лица ( деятельность 5)
10. Услуга 5 юр лица ( деятельность 5)
Естественно %5 уже не подойдет, так как будет возвращать совершенно другие результаты. Как можно выкрутиться?

Сделать нормальную нумерацию (два поля). И соответственно переписАть весь код, в котором использован этот феерический бред.

Цитата Отшельник @ 17.03.15, 15:09

7%4 = 3. т.е. id деятельности = 3

А если будет не 7, а 4, то будет 4%4 = 0, а надо же 4!

Цитата Отшельник @ 17.03.15, 15:09

есть перечень услуг

У тебя не перечень услуг, а их список, оказанный лицами. Перечень услуг - это словарь вида ID -> Value. Что такое внешние ключи и с чем их едят - знаешь?

Цитата Akina @ 17.03.15, 15:13

Сделать нормальную нумерацию (два поля). И соответственно переписАть весь код, в котором использован этот феерический бред.

с радостью, только этот перечень жестко забит в Items компонента, а Tag компонента - и есть ID.

Цитата Славян @ 17.03.15, 15:22

А если будет не 7, а 4, то будет 4%4 = 0, а надо же 4!

верно, описочка )

Цитата #SI# @ 17.03.15, 18:02

У тебя не перечень услуг, а их список, оказанный лицами. Перечень услуг - это словарь вида ID -> Value. Что такое внешние ключи и с чем их едят - знаешь?

конечно. Только разработчик не я. Мне теперь доработать/ исправить малой кровью необходимо.

Не хотелось конечно многого изменять, но похоже другого варианта как вынести данный перечень в таблицу Id, Type, Name и переписать все процедуры и вьюхи c join-ом на данную таблицу не остается...
Akina , вы это имели ввиду?

Цитата Отшельник @ 17.03.15, 20:46

разработчик не я. Мне теперь доработать/ исправить малой кровью необходимо.

У меня аналогичный случай (рядом, в Oracle). Второй год дорабатываю то, что накосячили 15 лет назад. Ничё, почти закончил .

Цитата Отшельник @ 17.03.15, 20:46

вынести данный перечень в таблицу Id, Type, Name и переписать все процедуры и вьюхи c join-ом на данную таблицу

И всё??? Так удачи тебе!

Цитата Отшельник @ 17.03.15, 20:46

Akina , вы это имели ввиду?

Не совсем.
В данном конкретном случае я не вижу необходимости синтетического ключа-автоинкремента. Считаю более разумным его убрать и ввести два поля Категория (услуги физ. или юр. лиц) и Деятельность (1, 2 и т.п.). Первичным ключом назначить совокупность этих полей. Или, если СУБД умеет, то дополнительно ввести (и назначить первичным ключом) вычисляемое поле на основе этих двух, например =100*Категория+Деятельность.
Другой вариант (он мне нравится гораздо меньше - в первую очередь именно тем, что всё равно останется это целочисленое деление) - остаться в рамках одного поля, но значительно расширить его по диапазону. Например, первые две цифры определяют Категорию, вторые две - Деятельность. Это даст возможность ввести до сотни Категорий, и в каждой до ста Деятельностей.

Цитата Отшельник @ 17.03.15, 15:09

Естественно %5 уже не подойдет, так как будет возвращать совершенно другие результаты. Как можно выкрутиться?

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

Если данные хранятся в БД PostgreSQL (про другие БД не скажу, тож должно кое-где быть) - можно использовать тип поля "Bit string type", и посмотреть в сторону использования (и правильности использования) GiST - индексов. Но использование целого в качестве хранителя битов - всеж должно быть проще и быстрее. ИМХО.

Цитата Отшельник @ 17.03.15, 20:46

с радостью, только этот перечень жестко забит в Items компонента, а Tag компонента - и есть ID.

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