Как лучше хранить GUID в базе (тип данных)?
GUID как PK, база Postgresql, для Oracle тоже интересно. В связке с EF.
Что скажете?
MS в своих примерах любит строки. Но что то многим это не нравится.
Как дефолтно хранится, так и храню
А какой именно тип в базе? База ПГ?
А как начну семь знаков за работу получать, так тоже думать об этом начну
Что то мне кажется тогда уже будет поздно 
Вообще то никогда не имел связи между зарплатой и типом раздумий.
GUID как PK, база Postgresql, для Oracle тоже интересно. В связке с EF.
Мнэ... Let me google it for you, понимаешь. https://www.postgresql.org/docs/current/datatype-uuid.html Вот только про связку с EF ничего сказать не могу.
Let me google it for you
но там нет сравнения различных способов
Это первое, что интересовало.
Второе, что делает EF по умолчанию. Это я уже знаю - оракле: raw, постгрес: uuid
И третье, как как сделать преобразование базы оракле в постгресс с наименьшими затратами если "там есть" Guid.
Не забыть и про изменения в софте. Желательно никаких.
там изначально не дается гарантии на уникальность
"the chances of generating a duplicate GUID : 1 in 2^128;"
пока хватает, да и так уже сделано.
Если не хватает размера ключа
дело разве в этом было, что так сделали или делают?
но там нет сравнения различных способовЭто первое, что интересовало.
Так тебе шашечки или ехать?
Определись какие способы сравнивать собираешься.
Надеюсь, достаточно очевидно что на хранение 128-и битного поля бд потратит туро меньше места чем на строку.
Не забыть и про изменения в софте. Желательно никаких.
В том же EF и подобных ORM должна быть как минимум перегенерина прослойка доступа к БД. А сами вызовы методов прослойки вроде и не меняются.
И третье, как как сделать преобразование базы оракле в постгресс с наименьшими затратами если "там есть" Guid.
Есть какие-то другие преобразования, кроме копирования данных из таблиц с вызовом newguid, newid (или подобного) для каждой новой строки? Неважно, гуиды это или обычный интегер.
Новая БД - новые идентификаторы. Только остальные данные можно полностью скопировать.
кроме непомерной глупости
Это не аргументы, всегда есть плюсы и минусы.
для ГУИДов нет гарантии не повторения
А отчего это должно волновать, с подобной вероятностью, в данном конкретном случае?
А даже если и будет получен не уникальный ид, какой катастрофой это будет нам грозить?
Так тебе шашечки или ехать?
Хотелось бы найти критерии выбора для каждого случая.
Пока есть две вроде 2 группы: строки и цифровая форма.
то на хранение 128-и битного поля бд потратит меньше места чем на строку
Скажем так - недостаток 1, и во всех ли случаях нам это будет интересно?
Какие еще есть?
Из достоинств, как кажется:
- 100% переносимость
- Минимум конвертаций, если пользуем json
- Что вижу то и "пою". Блин, сейчас с ораклом просто катастрофа. При отладке видишь одно, в при просмотре базы совсем другое.
А отчего это должно волновать
------
Я вот не припомню, чтобы в каком-нибудь софте случалось видеть обработку ошибки уникальности первичного ключа...
Судя по вопросу - ключи генерятся не на сервере, а клиентами - т.е. там вообще бардак гарантируется...
какой катастрофой это будет нам грозить?
-----
А что будет результатом выборки при наличии двух и более одинаковых ПК?
А какая именно будет первой?
а я вот не припомню
------
https://it.wikireading.ru/20048
Хотя да, исключения могут быть
-----
Именно так...
В том же EF и подобных ORM должна быть как минимум перегенерина прослойка доступа к БД. А сами вызовы методов прослойки вроде и не меняются.
Поэтому, кстати, и не нужна эта самописная устаревшая херота типа "repository pattern". Максимум, если там какая-то лютая кастомная транзакция с задействованием кучи сущностей - ну пишешь её в отдельную функцию.
А сами вызовы методов прослойки вроде и не меняютсяне меняются. А если народ любит code first?
А это тут причём? Коде фёрст это описание модели, а функционал вы берёте от изкоробочного базового класса с поддержкой EF интерфейсов типа IQueryable, если мне не изменяет память.
Новая БД - новые идентификаторы. Только остальные данные можно полностью скопировать.От подобных заяв волосы дыбом встают
Приведите заявы получше. Я не эксперт - я бы тупо скопировал данные из таблиц с новой генерацией ключей. Вы бы ключи тоже скопировали? А там есть возможность выбирать, будут ключи копироваться или генериться? Как механизм БД распознает, как генерить следующие ключи после вставки кучи готовых? Когда БД сама генерит от начала и до конца, то ей норм, а когда всякие вмешиваются в этот процесс в погоне за призрачными оптимизациями, то могут вознинуть сложности.
На вот попробуй
CREATE TABLE [dbo].[AspNetRoles] (
[Id] NVARCHAR(128) NOT NULL,
[Name] NVARCHAR(256) NULL,
[NormalizedName] NVARCHAR(256) NULL,
[ConcurrencyStamp] NVARCHAR(MAX) NULL,
CONSTRAINT [PK_AspNetRoles] PRIMARY KEY ([Id])
);
CREATE UNIQUE INDEX [RoleNameIndex]
ON [dbo].[AspNetRoles] (
[NormalizedName] ASC
);
INSERT INTO [dbo].[AspNetRoles] ([Id], [Name], [NormalizedName], [ConcurrencyStamp]) VALUES
('27163748-00f8-4725-8d4e-9dce62923f2c', 'TestAdmin', 'TESTADMIN', 'af32e894-1def-4665-b7be-dff048774f1a');
INSERT INTO [dbo].[AspNetRoles] ([Id], [Name], [NormalizedName], [ConcurrencyStamp]) VALUES
('274e474d-a20d-48a6-ab9a-f260a88fec43', 'TestStudents', 'TESTSTUDENTS', 'e8d8fa37-89b5-4f9d-bdc4-476111593ce9');
INSERT INTO [dbo].[AspNetRoles] ([Id], [Name], [NormalizedName], [ConcurrencyStamp]) VALUES
('274e474d-a20d-48a6-ab9a-f260a88fec43','abs','abs','e8d8fa37-89b5-4f9d-bdc4-476111593ce8');
[Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Violation of PRIMARY KEY constraint 'PK_AspNetRoles'. Cannot insert duplicate key in object 'dbo.AspNetRoles'. The duplicate key value is (274e474d-a20d-48a6-ab9a-f260a88fec43).