Вопросы Теги

Это плохо для разработки базы данных, которые позволяют пользователю обновлять PK?

Ну, если Вы не сохраняете журналы, лучшее, которое можно сделать, откатывают к последнему различному.

То, что я обычно делаю, скопировать журнал транзакций на намного более коротких интервалах (возможно, каждые 15 минут или так). Это препятствует тому, чтобы я терял много данных в худшем варианте (машина сгорает дотла). Это - очень легкая операция, таким образом, это может быть сделано онлайн с минимальным влиянием.

Необходимо обычно только использовать режим Полного резервного копирования, и необходимо часто создавать резервную копию журнала транзакций, если Вы не можете позволить себе проиграть до ценности целого дня данных, которые являются тем, чему Вы подвергаетесь теперь.

0
задан 25 July 2010 в 05:30
3 ответа

Плохо. Если PK регулярно изменяется (не как часть некоторого reogrinanization) затем, это не был естественный PK, или проектирование приложений плохо.

4
ответ дан 4 December 2019 в 11:22
  • 1
    , Что действительно "отделяется некоторого reogrinanization", означает? Вы могли дать мне некоторый пример? –  Ekkapop 25 July 2010 в 05:41
  • 2
    Ekkapop: если необходимо изменить первичные ключи при завершенном перепроектировании схемы базы данных это ожидается. Если необходимо обновить первичный ключ, потому что кто-то женился, это плохо. –  freiheit 25 July 2010 в 05:43
  • 3
    Точно. Подобный исчерпал бы первичные ключи и присвоил бы больший тип, например. Пример: Номера аккаунта - 8 цифр, внезапно 12 цифр долго. Если Вы используете "реальные" поля для PK. Это - reorganinization. –  TomTom 25 July 2010 в 05:54

Это звучит твердым кодировать для. Вы изменяете первичный ключ для записи, и необходимо изменить все ссылки на тот первичный ключ во всех таблицах. Легкий испортить. Просто используйте последовательность (или auto_increment или безотносительно) и сделайте первичный ключ, который не является данными. Или выберите первичный ключ, который это будет когда-либо должно действительно вряд ли изменить.

2
ответ дан 4 December 2019 в 11:22

Это было отчасти сказано, но (моя) лучшая практика должна всегда называть первичный ключ 'идентификатором' и делать его сериалом (автоинкрементное целое число) (целое число идентификационных данных в MSSQL). Это произошло с моим во многих случаях, что я должен был изменить PK, когда это был некоторый естественный ключ как чье-то имя.

0
ответ дан 4 December 2019 в 11:22
  • 1
    Если существует фактический PK в данных, нет действительно никакой потребности в суррогате. –  Ben Pilbrow 25 July 2010 в 12:36

Теги

Похожие вопросы