D
ты имеешь в виду - чтобы у каждого офиса была своя нумерация, которая в общей таблице не уникальна?
ага
Size: a a a
2020 January 14
D
у меня +- похожая таска
D
когда мне сказали так сделать,переглянулись друг на друга прогеры.. лучше не надо 🌚
VY
тогда это должны быть не id записей, а отдельное поле
D
ага
D
за AI , которым следить будешь сам
VY
D
потому что primary key в таблице может быть лишь один 🌚
D
за AI , которым следить будешь сам
вот эта логика при описании кажется будет довольно уродливой
VY
за AI , которым следить будешь сам
ну, тут уже и не АЙ... а что-то иное
VY
вот эта логика при описании кажется будет довольно уродливой
на самом деле наверно можно обойтись запросом с max() - по требуемому полю в связке с offise_id
D
а если это первая запись?)
D
и предыдущей нету :D
D
ну это уже так,придирки
ЕК
Всем привет. Есть вопрос. Работаю над проектом, в котором структура пользователей примерно такая - неограниченное число офисов, в каждом офисе - директор и менеджеры, у которых свои заказы, клиенты и т.п. Вопрос, собственно говоря, в следующем. Пытаюсь понять, как лучше спланировать базу? Либо общие таблицы заказов и т.п. для всех, и выборки по айди директора/офиса и т.д., либо под каждый офис свои таблицы с айди офиса в названии, которые будут создаваться динамически при регистрации нового офиса. У второго варианта плюс - таблицы будут гораздо меньше, чем была бы общая для всех, но минус - не будет модели и обращаться к ним придется через конструктор запросов, а не через модель. Вот пытаюсь понять, как, все-таки, лучше сделать
ээ...
RK
а в чем проблема сделать модель офис со своими айдишниками у которых есть например поле number которые в скупе будут индексом?
ЕК
А в чём проблема?)
VY
для этого случая писать отдельный метод
RK
index = id + number
ЕК
office has many employers
employer has many orders
employer has many orders