Суть предложения такова. Допустим, храним емаилы пользователей в базе. Можно сделать таблицу, типа: [id] [from] [to] [theme] [message] [time] А может разнести эту всю кучу малу по разным таблицам. То есть создать для каждего юзера таблицу с названием prefix_mail_to, где to - будет маил пользователя, без домена, например. Ну и сама таблица будет вида: [id] [from] [theme] [message] [time] Тем самым упрощаем задачу субд, по перелопачиванию большого объёма данных. И можно не напрягаясь писать интерфейс с кучей запросов к таблице, не парясь о нагрузке на сервер. Как считаете, хорошая идея, нет?
фраза не имеет смысла. что нагружает базу и какие у тебя запросы ты хоть расписывал? Пока просто "а если перевернуть вверх ногами вдруг она полетит?"
Горбунов Олег скорее root of evil - это навешивание ярлыков. Ему вполне определенно подошло время думать о скорости, но взялся он не с того конца. Стоит подсказать нужный конец, а не говорить "брось и не занимайся".
Сам то, сам то... ))) Тут на самом деле надо ответить сначала на простой логический вопрос: Является ли хранение _этих_ данных узким местом, и в чем мы выигрываем, сделав такое разбиение?
Горбунов Олег, нихрена не согласен, тогда «After optimization is way to the hell». Нет ну смотрите, если писать к почте вёб интерфейс. К примеру запрос для создания страничек не плохо будет базу тормашить, если всё будет в куче, а тут, пожалуйста, в маленькой табличке хоть завызывайся. Любые селекты не будут так сильно напрягатьбд, как при свалке в одной куче. То же касается сортировки и поиска по сообщениям. Ведь в таком случае бд просто перелапачивает одну таблицу, а так ей ещё нужно по полю [to] сначала из таблицы все записи выдрать, а потом уже в них копаться. Или я чего-то не догоняю?
запросы страничек не создают. цифры? примеры запросов? да. Для начала распиши что такое индексы и зачем.
Ti, ну точно. Предположим в таблице пара миллионов записей SELECT * FROM mes WHERE `to` = [email='login@domine.com]'login@domine.com[/email]' AND `from` like '*domain.com' AND `mes` like '%sell%' AND `theme` like '%word%' ORDER BY `time` DESC Предположим в локальной таблице 500 записей SELECT * FROM mes_login_at_domine_com WHERE `from` like '*domain.com' AND `mes` like '%sell%' AND `theme` like '%word%' ORDER BY `time` DESC
to сделать INT навешать индекс и будет у тебя скорость как у второй таблицы. другое дело INSERT/UPDATE =)
О! кажется до меня дошло. Человек предлагает вынести данные по пользователям в отдельную таблицу. )))) Danilka ты идешь в нужную сторону, но ОЧЕНЬ кривой тропинкой. оставь пока в покое таблицу с мейлами и распиши как понимаешь индексы. Я все-таки постараюсь добиться чтобы ты получил тут левел-ап. (не говорите про нормальные формы, сначала пусть индексы)
Есть таблица: [id] [login] [info] | 1 | vasya | fdgdf | | 2 | petya | fdgdf | | 3 | artem | sdafd | Создаём индекс по полю login, будет выглядеть примерно так: [id] [login] | 3 | artem | | 2 | petya | | 1 | vasya | При обращении к таблице 1 с условием where ligin = petya он сначала ищется в индексе, получается айди, потом выдёргиваются записи из первой таблицы. Ну при условии, что бд эзает id как идентификатор. Если основной индекс по логину сделать, то таблица, просто будет хнатиться, физически упорядоченная по логину. Вот так понимаю.
armadillo, это у меня одно из заданий по приему на работу. Ручками на любом ЯП реализовать работу индексов. )
armadillo, я думаю ты сам на этот вопрос не ответишь. Зависит от бд. Алгаритмов поиска целая туча. Ну к примеру, деления пополам, тогда 20.
Ну пологаю, что сначала бд её упорядочит, тоже каким-нибудь методом, а потом найдёт, тоже каким-нибудь. Ну а если не упорядочивать, то помима перебора, не вижу варианта.
если нет индекса - то полным перебором. Чтение из файла (работа с хдд), сравнение, чтение из файла... индекс выстраивает В ОПЕРАТИВНОЙ ПАМЯТИ дерево с минимальным количеством сравнений для поиска, сейчас используются В+ - деревья. По сравнению С ОДНИМ обращением к хдд за уже найденной записью количество сравнений в индексе неважно - 10, 15 и т.п., все равно меньше. То есть поиск в индексе происходит мгновенно по сравнению с перебором и практически не зависит от объема базы (точнее зависит логарифмически, но все равно меньше одного времени обращения к хдд).
То есть по-твоему одна таблица с индексами, по-любому лучше многих? Но ведь маленькие тоже можно сделать с индексами.
это означает, что если тебе нужно найти запись по ид, то время выборки будет сравнимо при размерах базы 10 и 10 000 000. Если две таблицы связаны про проиндексированному полю - то их пересечение будет выдаваться так же быстро, если по непроиндексированному - то перебором м*н вариантов. С тремя таблицами подсчитаешь? Теперь вернемся к нашим пользователям и емейлам. У нас много записей с разными сообщениями от одних и тех же пользователей - данные дублируются. Это плохо не только из-за объема, но и из-за неактуальности. У одного пользователя сменилось мыло, и сколько нам искать и менять? Что-то упустим. Лезем в гугль за словами "базы данных первая нормальная форма" и обсудаем эту тему тут так же как индексы.
Тогда ещё вопрос. Допустим у нас есть индекс по полю с сообщениями. И мы делаем поиск типа like %word% Все данные индексаполя сообщения будут храниться в ОЗУ? А если записей на неск. гигов? то бд всё это загонит в дерево и будит лопатить?
полнотекстовый индекс по текстовым полям - чуть более сложная и медленная штука. Лучше чем перебор, если нет другого выхода. Про него потом. Первая нормальная форма - это к логике структуре данных, как их разбивать по таблицам и зачем. Не гадай, найди.
Ну я как бы и спросил по-тому что прочитал. Первая нормальная форма (1NF) Таблица находится в первой нормальной форме, если каждый её атрибут атомарен и все строки различны. Под выражением "атрибут атомарен" понимается, что атрибут может содержать только одно значение. Таким образом, не соответствуют 1NF таблицы, в полях которых могут храниться списки значений. Для приведения таблицы к 1NF обычно требуется разбить таблицу на несколько отдельных таблиц. Пример приведения таблицы к первой нормальной форме Исходная, ненормализованная, таблица: Сотрудник Номер телефона Иванов И.И. 283-56-82 390-57-34 Петров П.Ю. 708-62-34 Таблица, приведённая к 1NF: Сотрудник Номер телефона Иванов И.И. 283-56-82 Иванов И.И. 390-57-34 Петров П.Ю. 708-62-34