⠀
не вижу в нем явных минусов
Size: a a a
2021 February 02
A
Привет всем!
Разрабатываю схему БД и столкнулся с такой проблемой: не знаю как лучше организовать структуру для категорий. Категория может иметь одну родительскую категорию. Следовательно категория может иметь множество дочерних категорий. Дерево, как есть.
Можно добавить в таблицу categories столбец parent_category_id. Таким образом восстанавливать дерево.
Можно создать отдельную таблицу parent_categories и вторую таблицу categories. Получится третья таблица, которая и будет показывать к какой родительской категории относятся обычные категории.
Я рассматривал два этих варианта, однако не знаю насколько они адекватны. Может ли кто-нибудь дать пару советов "как сделать лучше"?
Разрабатываю схему БД и столкнулся с такой проблемой: не знаю как лучше организовать структуру для категорий. Категория может иметь одну родительскую категорию. Следовательно категория может иметь множество дочерних категорий. Дерево, как есть.
Можно добавить в таблицу categories столбец parent_category_id. Таким образом восстанавливать дерево.
Можно создать отдельную таблицу parent_categories и вторую таблицу categories. Получится третья таблица, которая и будет показывать к какой родительской категории относятся обычные категории.
Я рассматривал два этих варианта, однако не знаю насколько они адекватны. Может ли кто-нибудь дать пару советов "как сделать лучше"?
буквально на одно сообщение выше ответ на подобный вопрос)
G
буквально на одно сообщение выше ответ на подобный вопрос)
Не ожидал такого, даже не смотрел историю выше. Только вот мне кажется, что у подхода через две таблицы есть явные минусы, которые можно предположить прямо сейчас: необходимость создавать третью, связующую таблицу; более затратное чтение; нельзя из дочерней или родительской категорий сделать обычную обновлением данных; в принципе нет обычных категорий (не родительская и не дочерняя)
A
Не ожидал такого, даже не смотрел историю выше. Только вот мне кажется, что у подхода через две таблицы есть явные минусы, которые можно предположить прямо сейчас: необходимость создавать третью, связующую таблицу; более затратное чтение; нельзя из дочерней или родительской категорий сделать обычную обновлением данных; в принципе нет обычных категорий (не родительская и не дочерняя)
там названы несколько алгоритмов для подобных структур
мне например нравится nested sets за удобный поиск потомков, но вот вставлять данные очень затратно в нее
мне например нравится nested sets за удобный поиск потомков, но вот вставлять данные очень затратно в нее
V
Всем привет!
БД: MYSQL
Влияет ли неявное приведение типов при выборке на производительность и значительно ли ?
Например, есть таблица товаров, и столбик XML_ID varchar(255) + создан индекс на XML_ID
1)
2)
БД: MYSQL
Влияет ли неявное приведение типов при выборке на производительность и значительно ли ?
Например, есть таблица товаров, и столбик XML_ID varchar(255) + создан индекс на XML_ID
1)
select * from products where XML_ID = "12345"
vs2)
select * from products where XML_ID = 12345
Будет ли выполняться второй запрос медленней, и значительно ли медленней ?EK
я думаю зависит от бд и конкретной версии
но в целом картина будет плюс минус одинаковая
запрос предварительно разбирается и все преобразования типов будут делаться там единожды, поэтому скорей всего НЕТ.
Гораздо лучше сгенерировать данные на пару гигов и проверить сделав benchmark заодно результатами его можно было бы поделится в канале
типо я вот нагенерировал данные
вот запрос что я делал и их время выполнения и среднее время (запускать надо не один раз и на прогретых данных или холодных)
вот explain хотя он тут врятли будет отличаться.
ну и выводы
но в целом картина будет плюс минус одинаковая
запрос предварительно разбирается и все преобразования типов будут делаться там единожды, поэтому скорей всего НЕТ.
Гораздо лучше сгенерировать данные на пару гигов и проверить сделав benchmark заодно результатами его можно было бы поделится в канале
типо я вот нагенерировал данные
вот запрос что я делал и их время выполнения и среднее время (запускать надо не один раз и на прогретых данных или холодных)
вот explain хотя он тут врятли будет отличаться.
ну и выводы
V
Сделали с коллегами Benchmark по нашему кейсу
БД mysql 5.7.21-21
Результат: С явного приведением данных к типу работает быстрее
Для результата использовалась таблица битрикса b_iblock_element на ~35400000 записей
Время выполнения с явный приведением 0.0016сек
Время выполнение без явного приведения 12.5 сек
Вывод: используйте явное приведение типов
Всем спасибо!
БД mysql 5.7.21-21
Результат: С явного приведением данных к типу работает быстрее
Для результата использовалась таблица битрикса b_iblock_element на ~35400000 записей
Время выполнения с явный приведением 0.0016сек
Время выполнение без явного приведения 12.5 сек
Вывод: используйте явное приведение типов
Всем спасибо!
EK
Сделали с коллегами Benchmark по нашему кейсу
БД mysql 5.7.21-21
Результат: С явного приведением данных к типу работает быстрее
Для результата использовалась таблица битрикса b_iblock_element на ~35400000 записей
Время выполнения с явный приведением 0.0016сек
Время выполнение без явного приведения 12.5 сек
Вывод: используйте явное приведение типов
Всем спасибо!
БД mysql 5.7.21-21
Результат: С явного приведением данных к типу работает быстрее
Для результата использовалась таблица битрикса b_iblock_element на ~35400000 записей
Время выполнения с явный приведением 0.0016сек
Время выполнение без явного приведения 12.5 сек
Вывод: используйте явное приведение типов
Всем спасибо!
👍
EK
ну было бы хорошо детали посмотреть бенчмарка но всегда можно повторить)
H
Помогите. Немогу найти скрипт который удаляет все foreign keys конкретного table сохранив их потом снова создает их после некоторых действией. Спасибо.
2021 February 03
ПМ
Артём
Доброго вечера! Подскажите, как лучше организовать вывод категорий и подкатегорий для интернет магазина. Для этого нужно 2 таблицы и 2 запроса (один - на вывод категорий, второй - на вывод подкатегорий). Или можно сделать одной таблицей.
на сколько я знаю, в таблице категорий делаешь столбец с id родительской категорией, соотвественно если 0 то у категории нет родительский и она на самом верхнем уровне. parent_id или как то так
ПМ
Можно и в одной это сделать. Но рационально будет в две таблицы
чем рационально? Всегда наблюдал что делают в одной
ПМ
Не ожидал такого, даже не смотрел историю выше. Только вот мне кажется, что у подхода через две таблицы есть явные минусы, которые можно предположить прямо сейчас: необходимость создавать третью, связующую таблицу; более затратное чтение; нельзя из дочерней или родительской категорий сделать обычную обновлением данных; в принципе нет обычных категорий (не родительская и не дочерняя)
не делай себе мозг, parent_id в таблице category и проблема решена, стандартная задача. Не разу не видел чтобы вообще по другому организовывали категории. И будет у тебя там древовидная структура. Не веришь, так возьми и создай таблицу с категориями и назначай одной несколько дочерних в parent_id а при условии выборки потом указывай это поле, ну это думаю и сам знаешь