И еще, одномоментно заменить все составные РК на UUID не удасться 100%.
Максимум, паралельно с составным РК иметь UUID, а это доп. связи/индексы, трафик... и прочие накладные расходы.
А уникальные индексы надо на UUID создавать (если это не РК) или можно таки поверить, что дефакто они никогда не повторяются???...
av1975И еще, одномоментно заменить все составные РК на UUID не удасться 100%.
Максимум, паралельно с составным РК иметь UUID, а это доп. связи/индексы, трафик... и прочие накладные расходы.
А уникальные индексы надо на UUID создавать (если это не РК) или можно таки поверить, что дефакто они никогда не повторяются???...
Де факто они никогда не повторяются.
P.S. Кстати в 9.0.2 они теперь введены как нативный тип, а не домен от varbinary(16), что облегчает работу с ними клиентских приложений (поддерживается автоматическое преобразование из стринга в значение и обратно). Во всяком случае в PB было достаточно неудобно работать с UUID, а с 9.0.2 все проходит просто на ура.
av1975Блин, сейчас все составными полями сделано, и сейчас удобный момент для внедрения UUID.
Лично я бы оставил все на составных полях - особенно если эти составные поля идут от смысла записей.
av1975Осталось только понять надо оно или нет.
И хочется и колется ...
И вообще, помни старый анекдот: Приходит сын к отцу-программисту: "Папа, а вот солнце каждый день всходит и заходит?" "Ты проверял, оно работает?" "Да" "НИЧЕГО НЕ ТРОГАЙ!"
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
