|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
30.07.2013, 21:15
|
|||
|---|---|---|---|
|
|||
Разбивать ли таблицу на части? |
|||
|
#18+
Есть смысл разбития таблицы? Даст ли это какой либо резон? Изначально таблица выглядела так Таблица urls idurlviewsauthorratingstatistik1statistik2statistik3statistik4statistik5statistik6statistik7...1 http://site.ru/o-bloge.html 5129998462541212...2 http://site.ru/kakoi-libo-adres.html 5129998462541212... тоесть обращаясь по адресу http://site.ru/o-bloge.html в таблице производится поиск по URL и формируется страница с этими самыми данными, (сколько просмотров, кто автор и куча всякой лабуды) ТЕПЕРЬ, один молодой и вроде как таллантливый малой посоветовал сделать такой финт - разбить таблицу на части якобы так со всех сторон эфектно Таблица url idurl1 http://site.ru/o-bloge.html 2 http://site.ru/kakoi-libo-adres.html и Таблица topicurl idviewsauthorratingstatistik1statistik2statistik3statistik4statistik5statistik6statistik7...15129998462541212...25129998462541212... товарищи профи, а в чём тут эфективность? а? Запросов к базе стало в 2 раза больше ведь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2013, 22:16
|
|||
|---|---|---|---|
|
|||
Разбивать ли таблицу на части? |
|||
|
#18+
Сержикин, судя по цитате автортоесть обращаясь по адресу http://site.ru/o-bloge.html в таблице производится поиск по URL и формируется страница с этими самыми данными ответ будет: действительно, "нахрена козе баян"?! Это же динамически создаваемая таблица. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.07.2013, 10:16
|
|||
|---|---|---|---|
Разбивать ли таблицу на части? |
|||
|
#18+
Сержикин, вынесении "длинного" поля в отдельную таблицу может оказаться выгодным по производительности. Это зависит от объёмов таблицы, и если в вашей СУБД нет возможности делать поискать по полю с url с использованием индекса. Суть выгоды: при поиске по полю url СУБД нет небходимости считывать всю запись из БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.07.2013, 10:19
|
|||
|---|---|---|---|
Разбивать ли таблицу на части? |
|||
|
#18+
АнатоЛойСержикин, вынесении "длинного" поля в отдельную таблицу может оказаться выгодным по производительности. Это зависит от объёмов таблицы, и если в вашей СУБД нет возможности делать поискать по полю с url с использованием индекса. Суть выгоды: при поиске по полю url СУБД нет небходимости считывать всю запись из БД. Поправлю: "Суть выгоды: при поиске по полю url во всей таблице ваша СУБД может вынуждена считывать всю запись. Если в ней нет других полей со статистикой, то объём записи будет меньше - и поиск по url будет производиться быстрее ". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.07.2013, 12:00
|
|||
|---|---|---|---|
|
|||
Разбивать ли таблицу на части? |
|||
|
#18+
АнатоЛой, Если СУБД не позволяет использовать [при поиске] индексы - то соединение двух таблиц тоже будет происходить весело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.07.2013, 12:03
|
|||
|---|---|---|---|
Разбивать ли таблицу на части? |
|||
|
#18+
Кот МатроскинЕсли СУБД не позволяет использовать [при поиске] индексы - то соединение двух таблиц тоже будет происходить весело. Вы недооцениваете фантазию разработчиков СУБД. Например, в Firebird я как-то наткнулся на очень суровое ограничение размера индексируемого поля, то есть number - запросто, а вот varchar(200) - говорил, слишком большое, в страницу не влазит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.07.2013, 12:24
|
|||
|---|---|---|---|
|
|||
Разбивать ли таблицу на части? |
|||
|
#18+
softwarer, Ну да, мне тоже при чтении топика вспомнились какие-то советы 1996 выпуска про еще тогда Interbase "выносите длинные поля в отдельную таблицу", но я все-таки надеюсь, что все эти макабры давно похоронены в чумной яме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.08.2013, 17:28
|
|||
|---|---|---|---|
Разбивать ли таблицу на части? |
|||
|
#18+
СержикинЕсть смысл разбития таблицы? Даст ли это какой либо резон? Изначально таблица выглядела так Таблица urls idurlviewsauthorratingstatistik1statistik2statistik3statistik4statistik5statistik6statistik7...1 http://site.ru/o-bloge.html 5129998462541212...2 http://site.ru/kakoi-libo-adres.html 5129998462541212... В чём эффективность разбивки, не знаю (это тонкий намёк на то, что её нет), а вот нарушение 1НФ налицо. Оно конечно, ваше дело, как с этим жить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.08.2013, 17:30
|
|||
|---|---|---|---|
Разбивать ли таблицу на части? |
|||
|
#18+
АнатоЛойСержикин, вынесении "длинного" поля в отдельную таблицу может оказаться выгодным по производительности. Это зависит от объёмов таблицы, и если в вашей СУБД нет возможности делать поискать по полю с url с использованием индекса. Суть выгоды: при поиске по полю url СУБД нет небходимости считывать всю запись из БД. Это зависит уже очень сильно от СУБД, потому что как правило все СУБД хранят физически такие длинные поля (BLOB/CLOB) отдельно от страниц с основными данными таблицы. Если это так, то нет смысла выносить такие поля в логической структуре БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.08.2013, 17:32
|
|||
|---|---|---|---|
Разбивать ли таблицу на части? |
|||
|
#18+
АнатоЛойАнатоЛойСержикин, вынесении "длинного" поля в отдельную таблицу может оказаться выгодным по производительности. Это зависит от объёмов таблицы, и если в вашей СУБД нет возможности делать поискать по полю с url с использованием индекса. Суть выгоды: при поиске по полю url СУБД нет небходимости считывать всю запись из БД. Поправлю: "Суть выгоды: при поиске по полю url во всей таблице ваша СУБД может вынуждена считывать всю запись. Если в ней нет других полей со статистикой, то объём записи будет меньше - и поиск по url будет производиться быстрее ". Ну, на самом деле не только и не столько поиск, как чтение и запись. Поиск, если по индексу, то он в одтельных страницах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.08.2013, 18:00
|
|||
|---|---|---|---|
Разбивать ли таблицу на части? |
|||
|
#18+
MasterZivСержикинЕсть смысл разбития таблицы? Даст ли это какой либо резон? Изначально таблица выглядела так Таблица urls idurlviewsauthorratingstatistik1statistik2statistik3statistik4statistik5statistik6statistik7...1 http://site.ru/o-bloge.html 5129998462541212...2 http://site.ru/kakoi-libo-adres.html 5129998462541212... В чём эффективность разбивки, не знаю (это тонкий намёк на то, что её нет), а вот нарушение 1НФ налицо. Оно конечно, ваше дело, как с этим жить.А с чего бы тут было нарушение именно 1-ой нормальной формы?! Для 1NF "необходимо и достаточно", чтобы атрибуты были атомарны. И в примере данных это, собственно, наблюдается... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.08.2013, 18:27
|
|||
|---|---|---|---|
Разбивать ли таблицу на части? |
|||
|
#18+
MasterZivАнатоЛойСержикин, вынесении "длинного" поля в отдельную таблицу может оказаться выгодным по производительности. Это зависит от объёмов таблицы, и если в вашей СУБД нет возможности делать поискать по полю с url с использованием индекса. Суть выгоды: при поиске по полю url СУБД нет небходимости считывать всю запись из БД. Это зависит уже очень сильно от СУБД, потому что как правило все СУБД хранят физически такие длинные поля (BLOB/CLOB) отдельно от страниц с основными данными таблицы. Если это так, то нет смысла выносить такие поля в логической структуре БД. А для того, чтобы получить ссылку на BLOB/CLOB, не придётся вычитать запись со всеми атрибутами? Или ссылка находится не в записи? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.08.2013, 18:29
|
|||
|---|---|---|---|
Разбивать ли таблицу на части? |
|||
|
#18+
MasterZiv Поправлю: "Суть выгоды: при поиске по полю url во всей таблице ваша СУБД может вынуждена считывать всю запись. Если в ней нет других полей со статистикой, то объём записи будет меньше - и поиск по url будет производиться быстрее ". Ну, на самом деле не только и не столько поиск, как чтение и запись. Поиск, если по индексу, то он в отельных страницах.[/quot] Я же как раз и сказал: АнатоЛойесли в вашей СУБД нет возможности делать поискать по полю с "url" с использованием индекса ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.08.2013, 18:30
|
|||
|---|---|---|---|
Разбивать ли таблицу на части? |
|||
|
#18+
Извиняюсь за неправильное форматирование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.08.2013, 19:25
|
|||
|---|---|---|---|
|
|||
Разбивать ли таблицу на части? |
|||
|
#18+
Если подходить к задаче буквально, то: становится ясно, что эта злополучная таблица является элеменарной агрегацией юзерских запросов к волшебному сайту http://site.ru; весьма сомнительно, что на сайте миллион, тысяча или даже "питсот" страниц!? От силы 100 страниц, то есть 100 строк в таблице. И что...поиск в трех соснах займет много времени? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&mobile=1&tid=1541156]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 247ms |
| total: | 503ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
