Запись в бд mysql, не повторяющиеся записи?

Question

[Игорь Федяев]

Привет всем. Направьте пожалуйста меня, не могу сам найти решение своей задачи. И так... Есть главная фирма в городе 1 где есть заказы и идентификация происходит по номеру заказа 1/1, 1/2, 1/3 (номер города/номер заказа) и главная фирма может создавать дочернюю фирму в городе 2 где есть заказы и идентификация происходит по номеру заказа 2/1, 2/2, 2/3 (номер города/номер заказа) , в городе 1 заказы не повторяются как и у города 2, как такое реализовать? Если вывести по id то не пойдет. Порядок должен идти строго - номер города/номер заказа.

Comments

[Daria Motorina]

Логика формирования номера заказа отличается от простого автоинкрементного id? Почему обязательно должен быть такой странный номер? Непонятен момент

Порядок должен идти строго - номер города/номер заказа.

Разве есть значение, как он в базе хранится? Главное ведь правила валидации и выборки нормально составить

[Дмитрий]

Вечер добрый.
Уникальный ключ на номер заказа.
При записи в базу будет выброшено исключение, если заказ с таким номером существует.
Или.
Номер города и номер заказа в разные поля таблицы. Оба эти параметры primary key.

[Игорь Федяев]

Daria Motorina, разница есть я в городе 1 создал 10 заказов, а в городе 2 создание продолжится от 10 и ТД. Это как то 6е серьезно

[Иван Мельников]

For MySQL:

CREATE TABLE `order` (
`no` SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
`city` TINYINT UNSIGNED NOT NULL,
FOREIGN KEY (`city`) REFERNCES `city` (`id`)
);

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

[ThunderCat]

Игорь Федяев,

а в городе 2 создание продолжится от 10 и ТД. Это как то 6е серьезно

Тяжело объяснять тупость такого подхода новичкам, но для примера - Вася, исполнитель, переехал из города 1 в город 2, перенеся все свои заказы, и тут (ВНЕЗАПНО!) у нас начинается лажа, так как мы посеяли все заказы Васи, по тому что в городе 2 у Коли уже были такие же номера заказов. Так как заказы и города это разные сущности, и их связь не является прибитой гвоздями форева. Это надо знать, учитывать и думать когда делаешь что-то сложнее сайта-визитки.

[Игорь Федяев]

ThunderCat, заказы должны строго находится в том городе где они были созданы. Читайте мой вопрос, вникните в смысл. Ваши предложения?

[ThunderCat]

Игорь Федяев,

Читайте мой вопрос, вникните в смысл.

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

Answer 1

[Талян]

Просто создаете UNIQUE ключ по двум полям city+ordr и все. Или я не так понял?
Что это за слеши? Или вы в каком-то поле так и собираетесь хранить заказы, как "1/2" и тд?

Comments

[Игорь Федяев]

Пользователь если зарегистрирован то номер города будет браться с users, так я узнаю откуда он, далее когда он формирует заказ, сохраняет и происходит запись в ячейку order где номер города/номер заказа

[Талян]

Игорь Федяев, сохраняйте в разные столбцы номер города и номер заказа.

[Игорь Федяев]

Талян, я в городе 1 создал 10 заказов, а в городе 2 создание продолжится от 10 и ТД.

[Талян]

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

2 AUTO_INCREMENT в одной таблице нельзя.
Возьмите в таблице столбец ID как номер заказа, пусть он будет AUTO_INCREMENT. Город сами какой надо впишете.

Количество заказов в данном городе определяйте как

SELECT SUM(*) FROM orders WHERE city=$city group by city;

Answer 2

[Иван Мельников]

For MySQL:

CREATE TABLE `order` (
`id` MEDIUMINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
`city_id` SMALLINT UNSIGNED NOT NULL,
FOREIGN KEY (`city_id`) REFERNCES `city` (`id`)
);

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

Comments

[Игорь Федяев]

Интересный код, надо попробовать.

[ThunderCat]

Во первых - что за имя поля - no? Кроме того что не несет в себе смысла, еще и не интуитивно, идентификатор сущности обычно называют id.
Во вторых - city - это связка с внешним ключом, ее именование тоже должно быть логичным - city_id, так как это не город, а его ид.
В третьих - smallint (<65535) для автоинкрементного ключа заказов и tynyint (<255) для городов - где логика?

[Игорь Федяев]

ThunderCat, какое ваше предложение?

[ThunderCat]

Игорь Федяев, Предложение - а давайте посчитаем количество городов хотя бы в России? И подумаем как и где использовать какие типы данных. Про количество заказов думаю понятно.

[Игорь Федяев]

ThunderCat, к чему вы ведёте? Конкретнее пожалуйста.

[ThunderCat]

Игорь Федяев, куда конкретнее? Тиниинт не годится для счета городов, как и смаллинт для счета заказов.

[Иван Мельников]

Игорь Федяев, ThunderCat, подправил.

Answer 3

[Руслан Федосеев]

Есть такие секретные слова - 1 нормальная форма бд, 2-я нормальная форма бд, 3-я нормальная форма бд...
Почитайте сначала теорию, а потом приходите с вопросами, если останутся...