The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Один из разработчиков MySQL раскритиковал проект и рекомендовал использовать PostgreSQL, opennews (??), 06-Дек-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


86. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от penetrator (?), 06-Дек-21, 15:24 
в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень очень давно (задолго до появления самого Azure)
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

98. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от Наме (?), 06-Дек-21, 16:12 
> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень
> очень давно (задолго до появления самого Azure)

Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское.

Ответить | Правка | Наверх | Cообщить модератору

101. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от penetrator (?), 06-Дек-21, 16:45 
>> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень
>> очень давно (задолго до появления самого Azure)
> Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское.

некластерный, heap или как хочешь еще, и он там есть и есть очень давно

PK в MSSQL может быть 2 типов

с пробуждением

Ответить | Правка | Наверх | Cообщить модератору

105. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от Наме (?), 06-Дек-21, 16:59 
>>> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень
>>> очень давно (задолго до появления самого Azure)
>> Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское.
> некластерный, heap или как хочешь еще, и он там есть и есть
> очень давно
> PK в MSSQL может быть 2 типов
> с пробуждением

Heap это, пардон, куча. Т.е. когда данные хранятся вообще вне всякой упорядоченной структуры, а просто страницы в цепочку выделяются по IAM. В Сибэйсе хренелион лет назад решили, что коль уникальный индекс практически всегда создаётся, то логично в структуре этого индекса хранить и все прочие данные, которые не входят в индексный ключ, а не отдельно кучу и отдельно би-три с листами с индексным ключом. Ну и сделали такою смесь верблюда с носорогом -- сверху служебные структуры би-три, а на листах все данные. Ну вот, эту хрень и назвали кластерным индексом. В принципе, логичное решение, но проблема в том, что одного индекса в типичных условиях никогда не бывает достаточно, а хранение всех данных в структуре какого-то одного индекса зачастую приводит к смещению статистик распределения со всеми печальными последствиями. Поэтому тот же Оракл такого не делал. Я уж не помню, когда они ввели что-то подобное, по-моему, с 12-той версии. В Слоне тоже такого не было.

Ответить | Правка | Наверх | Cообщить модератору

152. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от penetrator (?), 06-Дек-21, 22:53 
https://www.red-gate.com/simple-talk/databases/sql-server/t-.../

Heaps are tables without a clustered index.

Я вообще не собирался лезть в детали, я про то что в MSSQL ЕСТЬ КУЧИ.
Это онли про "Это в МС Сиквеле типично отношение реализуют "кластерным индексом", в Оракле типично куча"

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

Я только вернул кучи назад в MSSQL Server! С этим же все согласны? Ну вот и отлично.

Ответить | Правка | Наверх | Cообщить модератору

202. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Наме (?), 07-Дек-21, 11:43 
Не серчай. Вокруг этой темы перебор всякой терминологии. У многих в результате каша. Я просто попытался немного ситуацию прояснить.
Так что, PK (первичный ключ) это Ограничение и оно НИКОГДА не реализуется кучей. Реализуется "кластерным" (исходная куча тю-тю, если была) или доп. (некластерным) индексом (доп. в смысле дополнительным к исходной куче, которая в этом случае никуда не девается, просто по данным этой кучи строится В-древо, которое эти данные структурирует, что и упрощает с одной стороны поиск, с другой -- создаёт основу для реализации условия уникальности).
Ответить | Правка | Наверх | Cообщить модератору

107. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от Наме (?), 06-Дек-21, 17:01 
> PK в MSSQL может быть 2 типов

Как бы, PK это не индекс, а Constrain -- ограничение первичного ключа. Который реализуется, под капотом, созданием уникального кластерного уже Индекса, если явно не заказать создавать не кластерный индекс, а дополнительный.

Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

108. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от Наме (?), 06-Дек-21, 17:07 
> некластерный, heap или как хочешь еще, и он там есть и есть
> очень давно
> PK в MSSQL может быть 2 типов

Маленький бесплатный ликбез. В МС Сиквеле данные отношения могут хранится либо в куче, либо в би-три, организованном по значению уникального ключа (сортировки). PK же (Primary Key) это одно из видов Ограничений, которое реализуется либо тем, что все данные отношения помещаются в структуру индекса, либо тем, что создаётся куча, а куче создаётся би-три-структура доп. индекса, в которой на листах хранятся данные индексного ключа и ссылки на страницы кучи, где хранится оригинальная индексируемая строка.

Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

110. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Наме (?), 06-Дек-21, 17:18 
> Маленький бесплатный ликбез. В МС Сиквеле данные отношения могут хранится либо в
> куче, либо в би-три, организованном по значению уникального ключа (сортировки). PK
> же (Primary Key) это одно из видов Ограничений, которое реализуется либо
> тем, что все данные отношения помещаются в структуру индекса, либо тем,
> что создаётся куча, а куче создаётся би-три-структура доп. индекса, в которой
> на листах хранятся данные индексного ключа и ссылки на страницы кучи,
> где хранится оригинальная индексируемая строка.

Хотя, малыши, я тут несколько ошибся. Когда заказываешь PK к существующему уже отношению, в котором есть данные, то данные из кучи перемещаются в это би-три, а исходная куча удаляется, если же заказать PK при создании отношения, то и не будет создаваться, а сразу будет создано би-три, в который данные отношения и будут писаться. Если же создать PK и явно указать, что ограничение должно реализоваться доп. индексом, то будет к куче создан доп. индекс в виде би-три. Вот и всё.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру