Привет Николай
Уникальность ид-шников - это только часть проблемы, как зачастую тонко
подмечает в своих "бугага" Дима Коваленко :))
Например, нужен план действий, на случай, когда одна сущность одновременно
внесена в разных базах...
Эти вопросы здесь не поднимаю. Интересуют не проблемы логической
целостности, они в целом не привязаны к реализации сервера, мне кажется.
Что MS, что Firebird - по барабану. К тому же, это уже должен
программист сам думать и решать - это его хлеб, так ведь? А вот какие
могут быть технические проблемы в Firebird-базе (например с
производительностью запросов в такой базе) при варианте, когда ключевой
индекс формируется не обычным 1,2,3,4...., а описанным способом,
1001,2001,3001,...,1002,2002,4001 и тд, решающим, видимо, те же задачи,
что и первичный ключ на GUID, в принципе.
Хотя, пожалуй, выяснить это можно и самостоятельно - взять да нагенерить
пару-тройку миллионов записей разными способами, а потом покрутить
полученные результаты да сравнить. Главное - не упустить бы чего
эдакого, о чем и не подозреваешь. А переделывать базу будет уже поздняк
метаться...
VB> новые записи создаются как-бы "вперемежку", не последовательно, а
VB> втыкаются друг между другом. Не создаст это проблем в скорости поиска
VB> записей по первичным ключам? Типа дефрагментации первичного ключа, что
VB> ли?
Фантастика какая-то :))
Ну значит, видимо, проблем не будет :)
VB> Короче: есть подозрение, что абсолютно незнакомый мне термин "свойство
VB> монотонного возрастания" как раз про эти проблемы с вариантом 1 :)
Да нет, просто когда кадый последующий ид-шник больше предыдущего - очень
просто, хоть и не совсем верно по канонам, определять последнюю запись,
Последовательность записей, по-моему, лучше не по ID определять, а по
какому-нибудь полю SID - супергенератор, меняющийся и фиксирующийся при
каждом изменении интересующих нас записей свое значение в
соответствующем поле таких таблиц и отображающий последовательность их
появления или изменения. Я так делаю, у меня все прекрасно работает,
тьфу-тьфу. Правда до сих пор мне хватало принципа "таблица может
меняться только в одной из баз, другие принимают ее только ридонли", то
есть однонаправленная репликация таблиц, что ли. А сейчас возникает
необходимость поддержания таблицы с возможностью ее изменения в более
чем одной базе.
когда,
например, есть версионирование сущностей:
id_object
id_object_ver
object_name
Ох, я близко даже понять не могу, о чем Вы говорите. Не знаете ли Вы
каких ссылок интересных на эту тему, подучиться немного?
По крайней мере ясно, что у тех, кто с GUID работает как ключевыми
полями, этот вопрос не всплывает.
С уважением
Владимир
