В моем дизайне у меня много таблиц, в которых используются FK. Проблема заключается в том, что некоторые записи будут удаляться и повторно добавляться в различные моменты времени, поскольку они связаны с указанными c файлами проекта, ссылки всегда будут неточными, если я буду полагаться на традиционный идентификатор с автоматическим увеличением (поскольку каждый при повторном добавлении им будет присвоен новый идентификатор).
Ранее я задавал вопрос ( Sqlite - составной ПК с двумя автоматически увеличивающимися значениями ) относительно того, могу ли я создать составной автоинкрементный идентификатор, однако, по-видимому, это невозможно при ответе на вопрос, с которым я был связан.
Единственное автоматическое значение c, которое я могу себе представить, всегда будет уникальным и никогда не повторяется. полное значение даты, вплоть до второго - однако идея использования даты для идентификаторов таблиц выглядит как плохой дизайн. Итак, если я вместо этого помещу поле с полной датой в каждую таблицу и использую их в качестве ссылки FK, я смотрю на возможные проблемы в будущем? И правильно ли я считаю, что было бы более эффективно хранить его как целое число, а не как текстовое значение?
Спасибо за помощь
Обновление Чтобы уточнить, я не смотря на вопрос о первичных ключах. PK будет стандартным идентификатором автоинкремента. Я спрашиваю относительно оснований сотен ФК на датах.
Спасибо за ответы ниже, трудность, с которой я столкнулся, заключается в том, что я не могу найти аналогичную модель для изучения. В результате я бы хотел, чтобы приложение использовало файлы проекта (например, Word имеет файлы docx) для импорта данных в базу данных. После загрузки нового проекта записи предыдущего проекта очищаются, но их данные сохраняются в файле проекта (пользовательский формат файла приложения / текстовый файл), поэтому их можно добавить еще раз. Все FK будут основаны на проектах, поэтому они будут ссылаться только на те записи, которые существуют в данный момент в базе данных. Например, поскольку это приложение для создания мира, скажем, пользователь добавляет тип предмета, который будет иметь отношение к любому проекту (например, математике), из-за формы, в которую он введен в приложении, записи дается номер_типа 1 Это означает, что он сохраняется независимо от загруженного проекта. Однако другим типом субъекта может быть «Демонология», который применим только к загруженному конкретному проекту c (например, к фантастическому миру). Соединительная таблица school_subject нуждается в обоих в одной и той же таблице для ссылки на FK. Допустим, Demonology - это вторая запись в таблице типов субъектов, значение автоинкремента которой равно 2 - таким образом, таблица соединений записывает 2 как значение FK. Проблема в том, что перед повторным открытием этого проекта пользователь может добавить еще 10 типов объектов, которые являются универсальными и сохраняются, поэтому при следующем добавлении записей типов объектов проекта и записей school_subject демонологии теперь присваивается идентификатор 11. Однако таблица соединений school_subject повторно создается с той же записью, имеющей значение 2. Вот почему я хотел бы FK, который всегда останется прежним. Я не хочу, чтобы все проекты присутствовали в базе данных, потому что я хочу, чтобы пользователи могли создавать резервные копии и дублировать отдельные проекты, а также знать, что даже если приложение будет удалено, они могут повторно загрузить и заново открыть свои файлы проектов ,