Я согласен с P.Salmon в том, что структура вашего стола не идеальна. Создание собственного составного ключа, подобного этому, снизит эффективность поиска, поскольку это не будет быстрый поиск по индексированным ключам (например, вы можете искать «все заказы, сделанные вчера», «все заказы в этом году конкретным клиентом» или даже «какие продукты никто не покупает». Для каждого из этих поисков вам придется анализировать правильную информацию из составного ключа, то есть не только ваш запрос SQL будет возвращать каждый результат, но вам также придется анализировать каждый из них. результат и определите, является ли элемент с ключом 0015053020200412124523 частью заказа клиента 0530.
Одним из альтернативных решений будет таблица Orders, которая имеет отдельные ссылки на CustomerNo и ProductNo, плюс поле для даты. Вам также понадобится первичный ключ с автоинкрементом для таблицы, тогда вы можете использовать силу SQL и индексы (индексы?) Для любых запросов.
MySQL напрямую не поддерживает составные ключи, такие как некоторые другие системы баз данных делают, но в этом случае я не думаю, что это собираюсь сделать тебе больно. По крайней мере, вы не объяснили причину, по которой вашей системе нужен составной ключ по отношению к внешним ключам. Вы можете подделать составной ключ, используя хранимую процедуру для запуска вставки, или несколько других методов, но, опять же, я думаю, что это действительно приведет к тому, что с вашей базой данных будет трудно работать в будущем, и призываю вас переосмыслить вашу базу данных. дизайн.