Обмен данними (синхронизация бази)

[vitaly_l]

А если вместо ID добавить UID - составной индекс с ID записи и ID пользователя. Ето спростит или нет?

ID - записи, это уже уникальный индекс. Добавление к нему ID пользователя, делается для ускорения работы БД при больших объёмах данных. Во всех остальных случаях, такой составной индекс - ненужен.

А вообще, поле ID что означает? Если это просто номер записи (ну, типа, искусственный уникальный ключ в одной из таблиц), то его копировать в другую таблицу не стоит, т.к. в другой таблице он никакого смысла не имеет.

Если вы синхронизируете БД, то лучше чтобы и ID у них совпадали. т.к. от ID - зависит порядок записей в таблицах, а равно и другие индексы, включая UID. Особенно учитывая, что при грамотном проектировании БД из других таблиц ссылаются именно по ID. Соответственно если они будут не совпадать, то начнётся как раз та самая чехарда с индексами, на которую вы, кстати сами жаловались тремя записями выше.

[kit]

kit
А вообще, поле ID что означает? Если это просто номер записи (ну, типа, искусственный уникальный ключ в одной из таблиц), то его копировать в другую таблицу не стоит, т.к. в другой таблице он никакого смысла не имеет.

Например ID - номер товара и на етот ID ссилаютья другая таблица - продажа товаров. Поетому если менять ID нужно во всех таблицах?

[vitaly_l]

Поетому если менять ID нужно во всех таблицах?

естественно, синхронизировать нужно все таблицы.

[Vadim]

Например ID - номер товара и на етот ID ссилаютья другая таблица - продажа товаров. Поетому если менять ID нужно во всех таблицах?

естественно, синхронизировать нужно все таблицы.

И вот чтобы не заниматься такой дурной работой, каждому филиалу организации нужно выделять свой диапазон идентификаторов товаров, что и будет способствовать их несовпадению, и упростит синхронизацию.
Таким образом, если у Вас есть два филиала с отдельными базами, для первого филиала выделяется диапазон, к примеру, 100 000 ... 199 999, а второму - 200 000 ... 299 999. Теперь, при заведении новой записи для товара у первого филиала будет последовательность 100 001, 100 002, 100 003 и так далее, а у второго филиала - 200 001, 200 002, 200 003 и так далее.
В случае если оба филиала работают с идентичными товарами, тогда должен быть единый справочник товаров, который создаётся централизовано и рассылается филиалам по мере необходимости.

Добавлено спустя 5 минут 38 секунд:

Если вы синхронизируете БД, то лучше чтобы и ID у них совпадали. т.к. от ID - зависит порядок записей в таблицах

Вы всё перепутали. Как раз порядок записей зависит от индексов, т.к. в самой таблице все записи хранятся в беспорядке (специально выделил и подчеркнул). Дело в том, что порядок может меняться в зависимости от каких то условий. Как раз индексы и создаются, чтобы учитывать эти условия.

[vitaly_l]

vitaly_l писал(а):
Если вы синхронизируете БД, то лучше чтобы и ID у них совпадали. т.к. от ID - зависит порядок записей в таблицах

Вы всё перепутали. Как раз порядок записей зависит от индексов, т.к. в самой таблице все записи хранятся в беспорядке (специально выделил и подчеркнул). Дело в том, что порядок может меняться в зависимости от каких то условий. Как раз индексы и создаются, чтобы учитывать эти условия.

ID - это и есть уникальный индекс. https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82%D0%BE%D1%80

[Vadim]

ID - это и есть уникальный индекс.

Нет, это поле в таблице. Значения в поле могут быть (специально выделил и подчеркнул) уникальными только в том случае, если для этого поля создан индекс с явным параметром уникальности.

[vitaly_l]

vitaly_l: ID - это и есть уникальный индекс.
Vadim: Нет, это поле в таблице. Значения в поле могут быть (специально выделил и подчеркнул) уникальными только в том случае, если для этого поля создан индекс с явным параметром уникальности.

Именно поэтому у вас и проблемы с индексами. ID - это всегда уникальный индекс. Если это не так, то это уже не ID. <== Выучите это наизусть, повторяйте каждый час как главную мантру! и проблемы с индексами у вас, возможно, закончатся. Не верите мне?, тогда, прочитайте википедию: https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82%D0%BE%D1%80

[Vadim]

Именно поэтому у вас и проблемы с индексами.

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

[vitaly_l]

Дружище, у меня создалось впечатление, что Вы очень много курите.
У меня нет проблемы с индексами.

Я вот из-за этой Вашей фразы так говорил, и в ней вы говорите что у "Вас / 1С" постоянно рушатся индексы:

Код: Выделить всё

[quote="Vadim"]файлы DBF (по своему опыту с 1С) величиной более 1 ... 1,5 МБайт - это один сплошной геморой, т.к. постоянно рушатся индексы.[/quote]


Скорее всего, программисты из 1С - банально, не умеют синхронизировать, из-за того что там работают одни отличники .

[Vadim]

Я вот из-за этой Вашей фразы так говорил, и в ней вы говорите что у "Вас / 1С" постоянно рушатся индексы
...
Скорее всего, программисты из 1С - банально, не умеют синхронизировать, из-за того что там работают одни отличники

Дружище, это же было 20 лет назад. Где Вы нынче видели 1Ску работающую на DBF-ах?
Да и говорил то я совсем про другое, к синхронизации не имеющего никакого отношения...

Добавлено спустя 4 минуты 30 секунд:

Скорее всего, программисты из 1С - банально, не умеют синхронизировать,

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