| |
|
|
| | Существует база, в которой ключевые поля каждой таблицы заполняются счетчиком.
Планируется эту базу распосттринить в подразделения, не связанные сетью.
С целью анализа данные подразделений данные изредка (оценочно один раз в полгода-год) будут обьединяться в одну базу.
Для предупреждения конфликтов по ключевому полю планирую програмно генерировать значение этого поля по принципу максимальное значение этого поля в таблице +1, при этом само ключевое поле должно иметь префикс с кодом подразделения (4 цифры).
Например, для подразделения с кодом 4801 счетчик будет заполняться начиная с 48010000001 и т.д. - необходимо кол-во записей в каждом подразделении >10 млн
Вопросиы в следующем:
1. Какой тип данных задать для ключевого поля, и будет-ли нормально работать Double, Long Integer маловат.
2. Какие риски такого механизма.
К репликации душа не лежит.
Заранее благодарен за комментарии. | |
| |
| |
| |
|
|
| | Видимо, Double должно работать, как мимнимум 14(?) значащих цифр.
Можно и о String подумать. | |
| |
| |
| |
|
|
| | Для подобной задачи применял следующее решение
в филиалах есть поле счетчик как индентификатор записи
при экпорте во все таблицы добавляется поле с кодом филиала (для всех строк одинаковое значение) оно зашито в настроечной таблице
в главной базе (куда сливаются данные из всех баз) ключем являются 2 поля
Id - тот который счетчик в филиале
код филиала
все связи в сводной БД по 2-м этим полям
Ваше решение мне кажется менее универсальным и наглядным. | |
| |
| |
| |
|
|
| | 2 Serge Gavrilov & osmor
Большое спасибо за советы.
Думал над вариантом двух полей - хорошее решение для одной таблицы, в то-же время остерегаюсь проблем со связанными 2-я связями таблицами.
Также в главной базе неодходимо будет по-другому обрабатывать добавление записей - вместо счетчиков будет длинное целое.
На данное время склоняюсь к варианту "самодельного счетчика" с Double, при этом новое значение будет расчитываться и вставляться по событию "BeforeInsert" формы либо через SQL вместе с остальными полями.
Относительно String - здесь 2 аспекта - сложность и надежность расчета нового значение ключевого поля (для Double - Max+1), а также скорость выборки (работы подчиненных форм) по String -ключу.
Мои познания недостаточны для однозначного ответа по этим аспектим. | |
| |
| |
| |
|
|
| | Также в главной базе неодходимо будет по-другому обрабатывать добавление записей - вместо счетчиков будет длинное целое.
Не-е-е в ней тоже будет счетчик, а его значение будет дублироваться в поле длинное целое 
У меня было так что основная база использовалась только для анализа, в нее данные не добавлялись.
Связь была и по 5-ти полям (досталось в наследство), и ничего работало ... | |
| |
| |
| |
|
|
| | Спасибо за комментарий.
Связь по 5-и полям - это серьёзно  | |
| |
| |
| |
|
|
| | А вот есть такое поле, со значением GUID- этот гуид никода не повториться. | |
| |
| |
