Как предотвратить дубликат id из импортированной таблицы в MariaDB?

(перед этим я прошу прощения за мой плохой английский) У меня есть пример такой:

в настоящее время у меня проблемы с моим веб-приложением. Я сделал веб-приложение для одной компании. Я сделал приложение с помощью CodeIgniter 3.

я построил базу данных с помощью Maria DB. Для идентификатора в каждой таблице я использую автоинкремент ИД для моей базы данных приложений для каждой таблицы. Обычно я развертываю веб-приложение на облачном сервере (иногда у компании есть свой собственный выделенный сервер, но иногда нет ). Однажды есть компания, которую они не хотят развертывать приложение, которое я сделал раньше в облаке ( в целях безопасности, они сказали ).

эта компания хотела развернуть приложение на ПК сотрудника лично в офисе, в то время как ПК для каждого сотрудника не подключен друг к другу ( i.e автономный ПК / персональный компьютер / ноутбук сотрудника ). Они сказали, что каждые 5 месяцев они будут соберите все данные с персонального компьютера сотрудника в дата-центр компании, и, конечно же, дата-центр не подключен к интернету. Я сказал им, что это не лучший способ хранить их данные. (потому что данные будут дублироваться, когда я пытаюсь объединить все данные в один, так как мой идентификатор столбца для каждой таблицы находится в автоинкремент ИД, и это первичный ключ). К сожалению, компания по-прежнему хочет сохранить приложение таким образом, и я не знаю как решить эту проблему.

у них есть по крайней мере 10 сотрудников, которые использовали бы это веб-приложение. Согласно этому, я должен развернуть приложение на ПК 10 лично.

дополнительная информация: у каждого сотрудника есть свой уникальный идентификатор, который они получили от компании, и я сделал типа AUTO_INCREMENT код для каждого сотрудника, как в таблице ниже:

id   |  employee_id  | employee_name   |
1    | 156901010     |  emp1
2    | 156901039     |  emp2
3    | 156901019     |  emp3
4    | 156901015     |  emp4
5    | 156901009     |  emp5
6    | 156901038     |  emp6

проблема в том, когда они заполняют форму из этого приложения, некоторые из в таблице хранятся не id сотрудника, а новый id, полученный из increment id.

electronic_parts таблица. У них есть атрибут, как показано ниже: 
| id  |  electronic_part_name  |  kind_of_electronic_part_id  |

если emp1 заполните форму из веб-приложения, содержание таблицы, как показано ниже.

| id  |  electronic_part_name  |  kind_of_electronic_part_id  |
|  1  |   switch               |           1               |

и если emp2 заполните форму из веб-приложения, содержимое таблицы, как показано ниже. 

| id  |  electronic_part_name  |  kind_of_electronic_part_id  |
|  1  |      duct tape         |           10              |

когда я попытался объединить содержимое таблица в центр обработки данных будет разваливаться, потому что дубликат id.

становится хуже, когда я думаю о моих внешних ключей в других таблицах.. например,customer_order таблица.

в таблице customer_order столбец выглядит как ниже (просто образец, а не фактическая таблица, но похожая).

|id  |  customer_name   |  electronic_parts_id  |  cashier(a.k.a employee_id, the increment id one, not the id that employee got from a company as i described above )  |
| 1  |   Henry          |           1           |              10              |
| 2  |   Julie          |           2           |              9               |

кто-нибудь знает как решить эту проблему ? или кто-то может предложить/порекомендовать мне хороший способ решить эту проблему ?

Примечание.: Каждый сотрудник имеет свою собственную базу данных для своего приложения, поэтому база данных не централизована, это автономная база данных, то есть я должен установить базу данных на ПК сотрудника один за другим

7
auto-increment codeigniter database duplicates mariadb

5 ответов

это нестандартные ситуации и нестандартные решения.

Я могу предложить вам два способа решения этой проблемы.

  1. вместо использования autoincrement для первичного ключа создайте UUID и используйте его в качестве первичного ключа. Относительно вероятности дублирования в случайных UUIDs: только после генерации 1 млрд UUIDs каждую секунду в течение следующих 100 лет

    в CodeIgniter вы можете сделать это с помощью следующий фрагмент кода.

    $this->db->set('id', 'UUID', FALSE);

    это создает шестнадцатеричный ключ из 36 символов (с 4 тире включенный.)

    ac689561-f7c9-4f7e-be94-33c6c0fb0672

    как вы можете видеть, он имеет тире в строке, используя Codeigniter DB функция вставит это в базу данных с тире, она все еще будет работать. Если он не выглядит чистым, вы можете удалить и преобразуйте строку в 32-символьный ключ.

    вы можете использовать следующую функцию с помощью [CodeIgniter идентификатор UUID библиотека][1].

    function uuid_key {
        $this->load->library('uuid');
        //Output a v4 UUID 
        $id = $this->uuid->v4();
        $id = str_replace('-', '', $id);
        $this->db->set('id', $id, FALSE);
}

    теперь у нас есть 32-байтным ключом,

    ac689561f7c94f7ebe9433c6c0fb0672

  2. альтернативный нетрадиционный метод для решения ситуации добавление функции для регистрации всех обработанных запросов Insert, Update, Delete на сайте к файлу локально. Таким образом, в каждом локальном реализация создаст файл журнала с фактическим списком запросы, которые изменяют БД с течением времени в правильном последовательном порядке.

    в любой момент времени, состояние база данных является результатом набор всех этих запросов произошел в прошлом до этой даты.

    так в каждых 5 месяцах когда вы будете готовы собрать данные от сотрудники персонального компьютера, вместо того, чтобы принимать дамп данных, возьмите это файл журнала запросов.(Примечание: такой журнал запросов не будет автоинкремент идентификатор, как он будет создан только в реальном времени, когда он выполняется в направлении базы данных. )

    используйте такие файлы для импорта данных в ваш центр обработки данных. Этого не будет конфликт как он будет генерировать autoincrements в вашем центре обработки данных в реальное время. (Надеюсь, вам не придется связывать свой локальный центр обработки данных в любой момент времени в будущем)

    [1]: https://github.com/Repox/codeigniter-uuid

9

это id используется в любых других таблицах? Он, вероятно, будет вовлечен в JOIN. Если это так, у вас есть большая проблема распутывания идентификаторов.

если id больше нигде не используется, тогда значения не имеют значения, и строки можно перенумеровать. Это будет сделано (грубо говоря) путем загрузки данных из различных источников в одну таблицу, но не включить id в нагрузку.

или, если есть какой-то другой столбец (или комбинация столбцов) это UNIQUE, затем сделать это the PRIMARY KEY и избавиться от id.

каком случае применяется? Мы можем продолжить более подробно. Пожалуйста, предоставьте SHOW CREATE TABLE для любой таблицы(ов), которые имеют отношение.

в моем первом случае (где id используется как FK в другом месте) сделайте что-то вроде этого:

при вставке строк в таблице с id, инкремент значения достаточно, чтобы избежать столкновения с существующими кодами. Затем do (в той же транзакции):

UPDATE the_other_table SET fk_id = fk_id + same_increment.

повторите друг для друга таблицу и каждый идентификатор, по мере необходимости.

3

Я думаю, что ваша проблема родом из вашего база данных... ты не очень хорошо его спроектировал. это ошибка Если у вас есть ID для двух пользователей разница .

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

просто инициируйте поле id, как это, и ваша проблема будет решена .

    CREATE TABLE [YOUR TABLE NAME](
        [ID]  int   NOT NULL    IDENTITY(1,1)   PRIMARY KEY,
....
2

требуется ли, чтобы id был целым числом? если нет, вы можете использовать префикс на id, чтобы вход для каждого сотрудника был уникальным в целом. это означает, что вы должны отказаться от автоматического приращения и просто рассчитывать на данные таблицы (предполагая, что вы не удаляете ни одну из записей.)

0

вам может потребоваться написать код на PHP, чтобы handel это. Если другая таблица уже следует за уникальным / первичным ключом, чем это нормально.

вы также можете сделать это после того, как импорт. вроде этого найти дубликаты в той же таблице в MySQL

0