Сообщение Re[49]: В России опять напишут новый объектно-ориентированны от 24.03.2018 9:49
Изменено 25.03.2018 13:55 vdimas
Re[49]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Ок, вижу, мы опять подошли к сложному месту. Попробуем объяснить.
S>Сначала — про возможность. Если мы выбираем целочисленные ключи, то, скажем, в MS SQL нет концепции "генераторов". Identity можно узнать только пост-фактум.
S>Можно попытаться "угадать" identity, взяв, к примеру, IDENT_CURRENT(). Увы — способ ненадёжен.
Разумеется ненадёжен и никто так не делает.
Несколько раз мне приходилось генерить ключи самому.
"Приходилось" означает, что другие решения были намного дороже.
И я видел аналогичное тоже не раз.
Оперирование ключами несложное — всё их потенциальное мн-во разбивается на иерархические кластеры, выдача ключей из кластера тривиальна. Пустые места замечательно склеиваются. При незначительном усложнении (если ожидается большой трафик удалений) то удаляемые ключи можно вовсе складывать в отдельный упорядоченный агрегат, каждая попытка записи в который провоцирует операцию слияния его содержимого с пустым пространством соответствующих кластеров. Собсно, так работает любой менеджер оперативной памяти, т.е. самая сложная-навороченная схема выдачи суррогатных ключей по сложности в точности равна менеджеру памяти. А более простая — намного проще.
==============
Вдогонку. Упомянутые алгоритмы управления памятью в данном случае имеют вырожденный случай (т.е. многие ветки алгоритма заведомо отсекаются), бо всегда надо выделять свободный "участок" длинной строго равной 1.
S>Ок, вижу, мы опять подошли к сложному месту. Попробуем объяснить.
S>Сначала — про возможность. Если мы выбираем целочисленные ключи, то, скажем, в MS SQL нет концепции "генераторов". Identity можно узнать только пост-фактум.
S>Можно попытаться "угадать" identity, взяв, к примеру, IDENT_CURRENT(). Увы — способ ненадёжен.
Разумеется ненадёжен и никто так не делает.
Несколько раз мне приходилось генерить ключи самому.
"Приходилось" означает, что другие решения были намного дороже.
И я видел аналогичное тоже не раз.
Оперирование ключами несложное — всё их потенциальное мн-во разбивается на иерархические кластеры, выдача ключей из кластера тривиальна. Пустые места замечательно склеиваются. При незначительном усложнении (если ожидается большой трафик удалений) то удаляемые ключи можно вовсе складывать в отдельный упорядоченный агрегат, каждая попытка записи в который провоцирует операцию слияния его содержимого с пустым пространством соответствующих кластеров. Собсно, так работает любой менеджер оперативной памяти, т.е. самая сложная-навороченная схема выдачи суррогатных ключей по сложности в точности равна менеджеру памяти. А более простая — намного проще.
==============
Вдогонку. Упомянутые алгоритмы управления памятью в данном случае имеют вырожденный случай (т.е. многие ветки алгоритма заведомо отсекаются), бо всегда надо выделять свободный "участок" длинной строго равной 1.
Re[49]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Ок, вижу, мы опять подошли к сложному месту. Попробуем объяснить.
S>Сначала — про возможность. Если мы выбираем целочисленные ключи, то, скажем, в MS SQL нет концепции "генераторов". Identity можно узнать только пост-фактум.
S>Можно попытаться "угадать" identity, взяв, к примеру, IDENT_CURRENT(). Увы — способ ненадёжен.
Разумеется ненадёжен и никто так не делает.
Несколько раз мне приходилось генерить ключи самому.
"Приходилось" означает, что другие решения были намного дороже.
И я видел аналогичное тоже не раз.
Оперирование ключами несложное — всё их потенциальное мн-во разбивается на иерархические кластеры, выдача ключей из кластера тривиальна. Пустые места замечательно склеиваются. При незначительном усложнении (если ожидается большой трафик удалений) то удаляемые ключи можно вовсе складывать в отдельный упорядоченный агрегат, каждая попытка записи в который провоцирует операцию слияния его содержимого с пустым пространством соответствующих кластеров. Собсно, так работает любой менеджер оперативной памяти, т.е. самая сложная-навороченная схема выдачи суррогатных ключей по сложности в точности равна менеджеру памяти. А более простая — намного проще.
==============
Вдогонку. Упомянутые алгоритмы управления памятью в данном случае имеют вырожденный случай (т.е. многие ветки алгоритма заведомо отсекаются), бо всегда надо выделять свободный "участок" длиной строго равной 1.
S>Ок, вижу, мы опять подошли к сложному месту. Попробуем объяснить.
S>Сначала — про возможность. Если мы выбираем целочисленные ключи, то, скажем, в MS SQL нет концепции "генераторов". Identity можно узнать только пост-фактум.
S>Можно попытаться "угадать" identity, взяв, к примеру, IDENT_CURRENT(). Увы — способ ненадёжен.
Разумеется ненадёжен и никто так не делает.
Несколько раз мне приходилось генерить ключи самому.
"Приходилось" означает, что другие решения были намного дороже.
И я видел аналогичное тоже не раз.
Оперирование ключами несложное — всё их потенциальное мн-во разбивается на иерархические кластеры, выдача ключей из кластера тривиальна. Пустые места замечательно склеиваются. При незначительном усложнении (если ожидается большой трафик удалений) то удаляемые ключи можно вовсе складывать в отдельный упорядоченный агрегат, каждая попытка записи в который провоцирует операцию слияния его содержимого с пустым пространством соответствующих кластеров. Собсно, так работает любой менеджер оперативной памяти, т.е. самая сложная-навороченная схема выдачи суррогатных ключей по сложности в точности равна менеджеру памяти. А более простая — намного проще.
==============
Вдогонку. Упомянутые алгоритмы управления памятью в данном случае имеют вырожденный случай (т.е. многие ветки алгоритма заведомо отсекаются), бо всегда надо выделять свободный "участок" длиной строго равной 1.