Моё почтение!
Хотелось бы обсудить душещипательный момент, с которым наверняка сталкиваются разработчики клиент-серверных комплексов...
Большинство таких приложений проектируются на долговременную перспективу, вот и я хотела бы предусмотреть большинство нюансов в процессе разработки...
мой комплекс состоит из 2х частей, первая часть - с локальной базой, 2я - на постгресе. 
надо разработать процесс обмена даными между этими 3мя системами, вот я придумала такой механизм:
в 1й части пользователь добавляет записи в таблицы, генерируются Id-поля для связи...
потом эти данные выгружаются из программы, пересылаются во вторую подсистему...
при добавлении этих данных, id записывается в таблицу соответствий, где в первом столбце - id полученный из первой подсистемы, а во второй - id, сгенерированный сиквенсом (?). это для того, чтобы предусмотреть выгрузку результатов проверки данных. выгружаются они с использованием той же таблицы соответствий...
естественно, что пользователь будет удалять записи как в 1й подсистеме, так и во второй....
я может что лишнее написала... просто запуталась, как бы мне избежать дырок в нумерации, ведь это неизбежно... возможно надо сделать какой-нибудь механизм сдвигов id, но как тогда избежать путаницы...
если кто-нибудь что-нибудь понял    из выше изложенного, помогите идеей... мне советовали сиквенс, но он не гарантирует заполнения свободных id-номеров

1. Синтетический первичный ключ, не несёт никакой смысловой нагрузки. Он не обозначает порядок вставки, он не перечисляет элементы, это просто некое число, которое уникально в пределах таблицы. Так что дырки в нумерации - это норма и бороться с этим никак нельзя, и даже наоборот вредно.

2. Если тебе надо реплицировать данные из нескольких подсистем, то тут есть несколько вариантов.
  а) использовать UUID Type
  б) использовать составной первичный ключ, одна колонка bigserial, вторая номер подсистемы (0 - для сервера, 1 - для первого клиента, 2 - для второго и т.д.)
  в) создать сиквенс с инкрементом 2 и на сервере начальное значение установить в 1, на клиенте 2, таким образом на сервере будут нечётные номера, на клиенте - чётные

А вот вариант с крос таблицей id-шников, лучше не использовать.

а чем плоха моя таблица соответствий?
ведь по сути она подходит под описание метода Б. У меня действительно планируется больше 2х подсистем, но взаимодействие между ними предполагается ступенчатое: 1я -> 2я -> 3я, аналогично обратная связь 3->2->1
номер ИД в обоих столбцах (сделаю оба ключевыми) нужен для повторной загрузки исправленных данных... то есть чтобы был замкнутый обмен, что ли... и при повторной загрузке будет сначала происходить поиск и редактирование уже существующей записи...
поэтому механизм обмена, в принципе будет эдентичным
чем такой алгоритм плох?

Это сообщение отредактировал(а) ImA - 13.3.2009, 09:17

Лишняя таблица (или даже несколько, по одной на каждую таблицу в базе). К тому же таблица достаточно объёмная <количество записей в системе>*<количество подсистем>. 

Целостность таблицы надо поддерживать полностью вручную. Например удалили мы из центральной системы запись №1, а из этой таблицы её можно будет удалить только после того как мы удалим её из всех подсистем. Т.е. надо ждать пока каждая подсистема не подтвердит, что удалила у себя эту строку. Или другой пример, в центре добавили строку в таблицу. Теперь надо дождаться пока присоединиться подсистема вставит у себя эту строку и вернет сгенерированный ID-шник.

Поэтому крайне желательно чтобы каждый элемент системы мог генерировать ключ который бы был уникален в пределах всей системы, без необходимости его конвертации. Если тебе не нравится составной ключ, посмотри в сторону UUID. Подобные ключи применяются во многих СУБД и их генерация не представляет трудностей.

"UUID : генерируя 1 триллион ключей каждую наносекунду, перебрать все возможные значения удастся лишь за 10 миллиардов лет."
Впечатлило   
Получается, что сгенерировав его однажды в первой подсистеме, я могу без боязненно этот же ключ вписать в остальные подсистемы... 
хммм... а его внушающие размеры не отразятся коренным образом на работе приложения? вполне возможно, что на местах работы 1й подсистемы будут совсем непотребное железо...
сейчас подумала... у меня на первой подсистеме - локальная база... парадокс, а там нет такого поля - UUID... прийдется делать стринг и генерировать в ручную?

Это сообщение отредактировал(а) ImA - 16.3.2009, 05:41

Замедление от перехода на UUID, будет настолько незначительным, что не стоит об этом беспокоиться.



Лучше использовать BYTES[16]. В Windows есть системная функция которая генерирует GUID, поищи в гугле примеры как её вызвать.

а как мне построить индекс на это поле? получается, что тип byte - вообще не может быть ни ключевым, ни индексированным   

В PostgreSQL лучше сразу использовать встроенный тип UUID. А насчет Парадокса, лучше спросить в разделе по Парадоксу.

перешла на акцесс... все-равно пришлось бы переделывать с бде на адо, а так, одним выстрелом - двух зайцев