Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
S>>А можешь объснить? S>> Я по коду смотрю мы заполняем 1 000 000 элементов таблицу
НС>Два раза по 1000000. НС>
НС>foreach (var batch in new[] {"First", "Second"}) ...
НС>
S>> и в ids должно оказаться 1 000 000, что и count
НС>2000000
Да но удаляются то страницы с первыми 1 000 000 целиком!
var tasks = new List<Task>();
var partSize = count / threadCount;
var localIds = new List<object>[threadCount];
for (int i = 0; i < threadCount; i++)
localIds[i] = new List<object>(ids.Skip(i * partSize).Take(partSize));
вот если ids рассортировать, а затем из них создать 5 массивов это правильнее!
Поэтому то они на филлфактор не влияют.
Но если заполнить 5 миллионов из 5 ти потоков (просто быстрее и заодно время замерить)
Затем получить 5 миллионов элементов, рассортировать массив и взять первый миллион будет правильно.
Или S>>можно и первоначальное заполнение из 5 потоков сделать
НС>Вот это уже точно ты сам.
В любом случе спасибо!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Поэтому то они на филлфактор не влияют. S>Но если заполнить 5 миллионов из 5 ти потоков (просто быстрее и заодно время замерить) S>Затем получить 5 миллионов элементов, рассортировать массив и взять первый миллион будет правильно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
S>>Поэтому то они на филлфактор не влияют. S>>Но если заполнить 5 миллионов из 5 ти потоков (просто быстрее и заодно время замерить) S>>Затем получить 5 миллионов элементов, рассортировать массив и взять первый миллион будет правильно.
НС>Займись.
С Новым годом!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Суть в том, что где то нет интернета или плохая связью и нужно работать оффлайн. S>И вот здесь прекрасно работают ГУИДы в качестве первичных ключей.
Глобальная уникальность на уровне записи даром не впилась.
Гуид назначается базе.
На уровне таблицы (для PK) используют обычные целочисленные идентификаторы.
Для идентификации объекта на уровне базы используют <идентификатор таблицы>+<PK записи>.
На глобальном уровне (при репликации) идентификатор объекта формируется из <идентификатор базы>+<идентификатор внутри базы>.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, Serginio1, Вы писали:
S>>Суть в том, что где то нет интернета или плохая связью и нужно работать оффлайн. S>>И вот здесь прекрасно работают ГУИДы в качестве первичных ключей.
КД>Глобальная уникальность на уровне записи даром не впилась.
КД>Гуид назначается базе.
КД>На уровне таблицы (для PK) используют обычные целочисленные идентификаторы.
КД>Для идентификации объекта на уровне базы используют <идентификатор таблицы>+<PK записи>.
КД>На глобальном уровне (при репликации) идентификатор объекта формируется из <идентификатор базы>+<идентификатор внутри базы>.
Все это прекрасно и понятно. Об этом я сам и писал. Но для репликации нужно еще дополнительные действия прилагать.
Суть Гуида в большинстве случаев интересен для увеличения параллелизма.
И заметь, что Guid v6 даже в википедии нет. Не особо то он и нужен значит.
Та же 1С в 7 ке как раз и использоваля префикс пререферийной базы и автоинкремент. В 8 ке отказались в пользу GUID.
Но GUID у них тоже своеобразный. Он формируется из нормального гуида но в нем есть дата и автоинкремент. https://infostart.ru/1c/articles/635159/
Плюс есть некие константные значения, которые копируются из разных баз.
Ну и часто приходится писать в базу 1С вне 1С. Используя NEWID https://forum.mista.ru/topic.php?id=465233
GUID просто удобнее ибо он практически уникален.
Еще пример премущества Гуида, это использование в заказах переданного гуида в качестве первичного ключа.
Не нужно отдельно создавать индекс для поиска заказа.
и солнце б утром не вставало, когда бы не было меня
