GUID в базах данных, отличных от SQL Server

Question

Вопрос: В данный момент я планирую базу данных для одной из моих программ.

Я намереваюсь использовать ASP.NET MVC для пользовательского бэкэнда, база данных находится в Linux и / или в Windows.

Теперь, даже если бы я делал это только для Windows, я должен был принять во внимание, что разные клиенты используют разные системы баз данных. Теперь я решил, что я использую nHibernate, затем я могу поместить все в код, и он работает на всех базах данных мэров, таких как Oracle / Sybase / MS / PostGre / MySQL / Firebird.

Моя проба сейчас GUID. SQL Server использует GUID, в то время как остальные используют целочисленное автоинкремент в качестве первичных ключей. Хотя автоинкремент лучше в теории, он создает проблемы с синхронизацией нескольких баз данных или проблемы, связанные с ручным изменением объектов, что требует импорта / экспорта CSV ...

Теперь, из-за проблем, присущих autoid на практике, мне больше нравится система GUID. И поскольку guid - это строка из 36 символов, я мог бы использовать varchar (36) в качестве первичного ключа, но varchar в качестве GUID может просто не быть идеальным решением ...

Как бы вы решили эту проблему / что вы используете в качестве первичного ключа? Или как избежать проблем с автоинкрементом, скажем, вставить CSV-файл, не меняя autoid ...

Answer 1

Ключ Guid, использующий ключ генератора guid.comb, можно использовать в любой базе данных, даже если он не имеет Guid как собственный тип.

Answer 2

У меня никогда не было проблем с использованием направляющих.Мы использовали Guid.Comb в системе со многими записями (миллионы), и у нас не было проблем из-за самих гидов.Для меня главное, что я могу генерировать идентификаторы, прежде чем что-то сохранить в базе данных.Даже на клиенте.Что очень полезно в сценариях CQRS.Единственное, что я думаю, вы также должны учитывать это удобочитаемость.Трудно смотреть на базу данных и сопоставлять записи в сценарии, скажем, master / detail.

И заметка о Firebird ... Uuid записывается в виде октета.И большинство клиентов, которых я использовал для управления базой данных, не могут представлять их в достойном формате.Поэтому он обычно отображается в виде пары символов (возможно, путем простого декодирования байтового массива в виде строки).Я не знаю о других провайдерах, хотя.SQLServer Management Studio, например, показывает их отлично.

Answer 3

Oracle и PostgreSQL также поддерживают GUID, в этом нет необходимости, поэтому используйте последовательности там (и, конечно, Диего прав: если вы используете свой собственный алгоритм для создания GUID, вы всегда можете сохранить использование столбца varchar с вашим собственным сгенерированным GUID)

Обратите внимание, что это пишется PostgreSQL, а не PostGre

Answer 4

Вы также можете рассмотреть возможность создания первичного ключа, который представляет собой комбинацию автоинкремента (т. Е. Настройки последовательности) и уникального идентификатора машины, на которой он был создан, возможно, с использованием MAC-адреса.

См. это для обсуждения.

Таким образом, у вас есть локально уникальный (благодаря последовательности) идентификатор, который также является глобально уникальным (благодаря части MAC-адреса).

Я знаю, я знаю, вы можете подделать MAC-адрес , но вы сами решаете, действительно ли это риск для вашего домена. Кроме того, возможность подделки может быть полезна при тестировании кода.

---

Пожалуйста, объясните лучше, что происходит, когда рождается новая клиентская БД. Будет ли он зарегистрирован на сервере? Если да, вы можете назначить DB-идентификатор на сервере и использовать его вместо MAC-адреса, просто назначьте номер каждой новой БД и используйте его вместе с последовательностью.

По сути, если вы хотите, чтобы «уникальный идентификатор экземпляра БД» избегал коллизий с «идентификатором таблицы», у вас есть только два варианта:

1) Сервер назначает идентификатор БД при каждом добавлении новой БД

2) Клиент автоматически генерирует уникальный идентификатор, и для этого обычно требуется использовать MAC-адрес, либо «сырой», либо обработанный каким-либо образом.

Честно говоря, я не вижу альтернатив, учитывая ваше текущее описание вашей проблемы.