Привет всем. Направьте пожалуйста меня, не могу сам найти решение своей задачи. И так... Есть главная фирма в городе 1 где есть заказы и идентификация происходит по номеру заказа 1/1, 1/2, 1/3 (номер города/номер заказа) и главная фирма может создавать дочернюю фирму в городе 2 где есть заказы и идентификация происходит по номеру заказа 2/1, 2/2, 2/3 (номер города/номер заказа) , в городе 1 заказы не повторяются как и у города 2, как такое реализовать? Если вывести по id то не пойдет. Порядок должен идти строго - номер города/номер заказа.
Вечер добрый.
Уникальный ключ на номер заказа.
При записи в базу будет выброшено исключение, если заказ с таким номером существует.
Или.
Номер города и номер заказа в разные поля таблицы. Оба эти параметры primary key.
а в городе 2 создание продолжится от 10 и ТД. Это как то 6е серьезно
Тяжело объяснять тупость такого подхода новичкам, но для примера - Вася, исполнитель, переехал из города 1 в город 2, перенеся все свои заказы, и тут (ВНЕЗАПНО!) у нас начинается лажа, так как мы посеяли все заказы Васи, по тому что в городе 2 у Коли уже были такие же номера заказов. Так как заказы и города это разные сущности, и их связь не является прибитой гвоздями форева. Это надо знать, учитывать и думать когда делаешь что-то сложнее сайта-визитки.
Спасибо что надоумили. Читайте мой ответ, вникните в смысл, который кстати достаточно прост - не гонитесь за "красотой" неповторимости номеров в городе, они и так будут уникальны если использовать встроенный механизм автоинкремента, пользуйтесь тем что уже миллион раз отработано - автоинкремент и внешние ключи, нормальные формы, связь один ко многим и многие ко многим и будет вам счастье.
Просто создаете UNIQUE ключ по двум полям city+ordr и все. Или я не так понял?
Что это за слеши? Или вы в каком-то поле так и собираетесь хранить заказы, как "1/2" и тд?
Пользователь если зарегистрирован то номер города будет браться с users, так я узнаю откуда он, далее когда он формирует заказ, сохраняет и происходит запись в ячейку order где номер города/номер заказа
Игорь Федяев, а, вы в этом плане. Ну я не особо вижу смысла в этом. Это только для того, чтобы видно было по выводу результата, что в данном городе данный заказ является таким-то?
2 AUTO_INCREMENT в одной таблице нельзя.
Возьмите в таблице столбец ID как номер заказа, пусть он будет AUTO_INCREMENT. Город сами какой надо впишете.
Количество заказов в данном городе определяйте как
SELECT SUM(*) FROM orders WHERE city=$city group by city;
Во первых - что за имя поля - no? Кроме того что не несет в себе смысла, еще и не интуитивно, идентификатор сущности обычно называют id.
Во вторых - city - это связка с внешним ключом, ее именование тоже должно быть логичным - city_id, так как это не город, а его ид.
В третьих - smallint (<65535) для автоинкрементного ключа заказов и tynyint (<255) для городов - где логика?
Игорь Федяев, Предложение - а давайте посчитаем количество городов хотя бы в России? И подумаем как и где использовать какие типы данных. Про количество заказов думаю понятно.
Есть такие секретные слова - 1 нормальная форма бд, 2-я нормальная форма бд, 3-я нормальная форма бд...
Почитайте сначала теорию, а потом приходите с вопросами, если останутся...
Простой
