Viper, спасибо!
Ну, в общем, я примерно так себе все это и представлял. Просто надеялся, что может быть, где-нибудь есть какая-нибудь компактная табличка, с описанием, когда какой ключ лучше использовать. =)
Ну, или у кого-нибудь есть простенький совет типа: когда у тебя в explain количество записей по запросу, который должен вернуть одну будет больше 50 - вводи индекс/еще одно поле в индекс
Омг.. JustUserR, простите за переход на личности, но Вы не устаете меня поражать! Седьмой раз читаю написанные Вами 3 строчки и все равно не могу понять, как это "может быть осуществлено распространение возможности"...
Причем, каждый Ваш ответ (на мои вопросы, по крайней мере) требует столь же долгого осмысления. И почти всегда оно столь же безрезультатно.
Конечно большое Вам спасибо за оперативные ответы, но мой Вам совет - почитайте "Капитанскую дочку".
Всем привет!
Похоже, я уткнулся в необходимость плотной работы с базами данных. А это значит, надо вплотную заняться их оптимизацией.
Первое, что приходит в голову - расставить индексы. Но даже это оказалось не так просто! Какое-то погуглив-почитав в рунетах, я понял, что четкости в понимании MySQL-ных индексов у меня совершенно не прибавляется. Даже скорее наоборот.
Потому решил обратиться к опытным товарищам с просьбой расставить над ними точки.
Итак, что я понял (не факт, что правильно):
1. Индексы ускоряют работу БД.
2. Индекс - это отдельный файл, который хранится на жестком диске и занимает место. Соответственно, не стоит их плодить слишком много.
3. Индекс - это что-то типа предметного указателя, т.е. то же самое поле, что и в таблице, только сортированное, скажем, по алфавиту.
4. Индексы могут быть разными (primary key, unique, index, fulltext), при этом какие-то из них (видимо - первые два) уникальные, то есть не могут существовать две записи с одним значением индекса, а какие-то (оставшиеся два) - не уникальные.
5. Для полнотекстовых индексов можно указать какую часть текста индексировать.
6. Индекс может быть натуральным (несущим смысловую нагрузку) и суррогатным (служащим только для идентификации записи)
Ок. Что я не понял.
1. Почему-то все пишут только про уникальные индексы, некоторые даже открыто заявляют, что неуникальные индексы не имеют смысла. Это, на мой взгляд, странно. Скажем, у нас есть таблица с топиками и таблица с комментами к этим топикам. И нам нужно выбрать все комменты к топику 2834. Комментов с topic_id=2834 будет куча (скажем 77, а всего записей, скажем - 100500), и проще их искать по индексу. Не так ли? Да. и правильно ли я понимаю, что для этого поля индекс должен быть типа INDEX?
2. Почему-то все рекомендуют создавать суррогатный PRIMARY_KEY на любых таблицах. Я не понимаю, зачем. Скажем, в той же таблице с комментами к топику. Зачем нужно делать comment_id, если с отдельным комментом никаких операций производиться не должно? Соответственно, он никогда не будет участвовать в WHERE и т.п.
3. Чем PRIMARY_KEY отличается от UNIC? Я так понял, что тем, что PRIMARY_KEY может быть только один в таблице. А в чем смысл?
4. Когда нужно использовать многостолбцовые индексы? Я так понял, что тогда, когда гм.. записей с одинаковым индексом по первому столбцу становится слишком много?
5. Где-то слышал, что лучше иметь один суррогатный PRIMARY_KEY, чем многостолбцовый индекс. Что выглядит логично - проще работать с одной колонкой, чем с кучей. Но я опять же не понимаю: допустим, нам нужно удалить все комменты юзера user_id из топика topic_id. Конечно, можно удалить комменты за номерами 4, 56, 58, 71, и это будет быстро, если comment_id - PRIMARY_KEY. Но. Вначале ведь нужно их как-то найти, эти значения!
6. Опять же, допустим, может возникнуть удалить все комментарии одного юзера из одного топика, а может - все комментарии в топике после 22-х часов. Но ведь не делать же под каждый такой вариант свой многостолбцовый индекс!
Проблема как раз в том, что в моем случае тэгов ожидается очень много. Больно уж широкой тематики сайт (наука, все отрасли), да и на тэги - основная смысловая нагрузка (библиотека, соответственно, ключевые слова - основа поиска по ней).
Но я тоже думаю, что, по крайней мере за первый год, длина таблицы вряд ли вырастит больше чем до 100 000 пересечений. Для таблицы из трех колонок интеджеров вроде не так уж и страшно звучит...
А вообще - с каких длин начинает падать база? =) Вопрос, конечно, не корректный, но все-таки. Так чисто по эмпирическим наблюдениям?
А мне, похоже, надо научиться понятно формулировать задачу.
Потому некоторые уточнения:
1. Задача состоит НЕ в визуализации. Для визуализации есть куча плагинов на том же jquery, ну и вообще это позже такой вопрос встанет.
2. Задача состоит НЕ в том, как определить вес тэга в статье (хотя Zuldek'у - большое спасибо, вероятно его алгоритм мне очень пригодится, когда станет задача расположения результатов в списке, выдаваемом по тэгу). Задача состоит в том, как определить соотношения между двумя тэгами - какие из них часто встречаются вместе (в поле "тэги"), а какие - редко.
Похоже, никто подобными проблемами не занимался, так что изложу свои мысли по этому поводу, может кто подскажет - какие из них больше походят на грамотное решение. =)
Мне пришли в голову два варианта решения.
Первое - самое очевидное. Сделать таблицу tag1_id, tag2_id и frequency (ну, и таблицу кодировок - id, tag_name, разумеется). Ну, и выбирать из нее все записи, где встречается tag1, а при добавлении статьи в БД, соответственно, увеличить на 1 frequency для каждой пары тэгов, записанных в поле "тэги".
Меня напрягает, что размер этой таблицы будет равен количеству записей в квадрате. Конечно, это в пределе. На самом деле, большинство тэгов никогда не встречаются вместе, и соответственно, не образуют записей в таблице.
Второе - немного менее очевидное. Сделать таблицу, в которой хранить связи тэг-статья. Т.е. tag_id, article_id. И тогда по запросу tag1 мы выбираем из этой таблицы, все статьи с этим тэгом, а потом - все тэги, упоминавшиеся в этой статье. Этот вариант мне нравится несколько больше, т.к. при необходимости, его можно расширить на поиск сразу по двум тэгам (опять же - не статей пока, а других тэгов). И вообще как-то он гибче выглядит.
Однако, тут меня напрягают 2 обстоятельства. Во-первых, при большом количестве статей размер таблицы будет примерно (количество статей)*10, что не факт, что меньше, чем (количество тэгов)^2. Во-вторых, я не большой знаток SQL, и не знаю пока, можно ли объединить два вышеописанных действия (SELECT article_id FROM table WHERE tag_id=tag1 и SELECT tag_id FROM table WHERE article_id=[все]article_id's), а если нельзя, то через php это делать будет просто адски долго.
Ну, зачем же так сурово?.. Думаю, тут можно и на JS все реализовать. Было бы желание..
Спасибо за ответы, однако, суть вопроса немного в другом.
Как организовать облако на странице - это туда-сюда, разобраться можно. Тем более, что в общем-то и не во внешнем виде суть.
Главный вопрос - как организовать сам процесс м.. создания этой "семантической сети" (назовем ее пока так). Особенно, меня интересует как сделать под нее таблицу в БД. Если бы можно было сделать таблицу, у которой тэги идут как в заголовках строк, так и в заголовках столбцов - то вроде все понятно. А в перекрестия этих строк просто ставить +1 за каждую встречу тэгов в одной статье. Но. По-моему в MySQL (да и в др. БД) это сделать не реально. А если бы было и реально - то крайне не эффективно: ведь тэгов может быть очень много! А иметь таблицу в 100500 полей..
Конечно, есть вариант сделать колонку tag1, колонку tag2 и колонку intersection, и записывать каждую пару тэгов. но ведь длина такой таблицы будет 100500^2! И что-то мне подсказывает, что должен быть какой-то метод более эффективный, о котором я не знаю..
Всем привет!
В общем, задача такая: сделать облако тэгов, но только такое, чтобы у нас тем крупнее был шрифт, и тем ближе к центральному слову были тэги, чем чаще они встречаются вместе с центральным тэгом. А не просто, чем чаще они встречаются вообще.
Допустим, клацнули мы по тэгу "PHP", у нас он сразу переехал в центр, и вокруг сгрудились и раздулись MySQL, Apache и HTML, а Basic и Access переехали куда подальше и стали едва различимым шрифтом.. Все потому, что одну статью часто помечают тэгами PHP, MySQL и html, а Basic с php почит не встречается. Ну, т.е. можно и без анимации, конечно. Это мне воображение так рисует картину порсто=).
Короче вот. Вопрос: кто-нибудь знает, как такое делается, или хотя бы - откуда копать?
Возникла задача тут.. Короче, имеется база данных и куча пользователей. Редактировать записи может любой пользователь. Задача, собственно, в том, чтобы сохранялись более ранние варианты записей. Типа, как это сделано в нашей любимой Википедии.
Вот. Собственно, вопрос - кто-нибудь знает, как это реализуется? Мне в голову приходит только тупо копировать запись каждый раз и сохранять под разными датами. Но как-то это.. очень уж не элегантно. Да и диски будет забивать влет.
Та же самая википедия, в статье о своем движке упоминает еще какое-то таинственное дельта-кодирование, но я так и не смог найти где-нибудь внятное объяснение, как его можно применить к текстам...
Всем привет! Проект:SciLacnce[dot]com. Суть проекта: фриланс-биржа для ученых и инженеров. Стадия: работает, реализованы базовые возможности. Проблема: по изначальному маркетинговому плану проект должен был включать в себя массу дополнительных возможностей: библиотеку, базу данных по грантообразующим организациям и т.п., за счет которых должно было осуществляться наполнение сайта на старте. Однако, ввиду того, что все программисты слились из проекта так ничего и не сделав, пришлось все делать самому, а сам я (поскольку не программист) смог реализовать только базовые возможности. В итоге сайт стоит пустой и даже чтобы его продвигать не за что взяться. А чтобы продвигать проект, нужно, чтобы программированием занимался другой человек. Задачи: создание дополнительного функционала сайта, оптимизация прежнего и т.п. Требования: главное – это желание и возможность (!) тратить на проект довольно много времени (почему-то для многих такая необходимость далеко не очевидна). Мне нужен именно партнер, а не просто программист, т.е. человек должен интересоваться именно самим проектом, а не, скажем, наполнением портфолио. Сайт по технологии web 2.0 с использованием AJAX и библиотеки JQuery, написан на php, с использованием фреймворка CodeIgniter, работает под Linux, так что знание всего этого, разумеется приветствуются. Оплата: не предусмотрена. Предусмотрен процент в учредительном договоре (от 5 до 40 – в зависимости от вклада в дело) Гарантии успеха: гарантий, как таковых, разумеется, нет. Но проведенные опросы показывают высокую актуальность решаемой проблемы. Конкуренты на рынке либо косвенные либо зарубежные, а тенденции развития российской экономики говорят о том, что рынок развивается достаточно динамично.
Viper, Спасибо! Но речь немного не о том.. С MVC я вродь знаком и ею именно и пользовался. Знаком и с ООП (не на 5+, но в целом понимаю, спасибо, кстати этому форуму во многом).
Суть вопроса в том, есть ли какая-нибудь книжка (или сайт какой-нибудь), по которой можно было бы изучить общую логику программирования как такового, а не какой-то конкретный язык? И, опять же, не какой-то конкретный подход, типа того же MVC.
Один мой знакомец учится на программиста в университете. У них там есть отдельный предмет "программирование". Не "программирование на С", а просто "программирование". И они там разбирают всякие типовые задачи, "как вообще писать программы", ту же рекурсию. Но я что-то не видел записей этих лекций (а даже если бы и увидел - они все равно на немецком, он в германии учится). Но наверняка есть же чего-нибудь в этом духе и на русском. Если бы я хотя бы знал, как такие книжки должны называться...
А это что такое? Почему так некрасиво налазит меню на текст?
оуч. Спасибо. Это я нововведение ввел - убрал скроллбар. и забыл протестить в IE... (Добавление)
З.Ы. Но это к делу не относится, это ж вообще CSS.
cHameleon пишет:
А у меня не налазит) у меня в ff скрипты запрещены)
ну, скрипты, если верить статистике w3c отключают около 4% пользователей.. можно их не учитывать особо.. На первых порах, по крайней мере. (Добавление)
Долго ли, коротко ли, прочитав несколько десятков книжек и статей про php и JS, я более-менее научился создавать сайты. Не удержусь и сошлюсь на мое последнее творение: http://scilance[dot]com . Тоже все-таки не персональная страничка, web 2.0 с применением AJAX и все такое. Но! Как был я быдлокодером, так и остался. Посмотреть на код профи приятно - например на код фреймворка (я пользовался CodeIgniter) - он напоминает аккуратную кирпичную кладку стены дома в маленьком альпийском городке. Мой же код напоминает приведенную ниже картинку. И речь идет не о том, чтобы соблюдать отступы и правильно расставлять скобки, одинаково расставлять горбы в названиях переменных и классов. Этому я более-менее научился. Речь об общей логике написания программ.
Профи пишут их как будто руководствуясь точным, рассчитанным до мелочей планом какого-то более глубокого уровня, нежели та самая блок схема работы программы, с которой рекомендуют начинать проект в самых продвинутых учебниках по программированию (о них ниже). Я сделал диаграмму! Я ей следовал! Но мой код все равно похож на лоскутное одеяло. Он состоит из сплошных затычек, заплаток и дыр.
Мне не хватает каких-то самых фундаментальных знаний о программировании.. Но где их взять? Все книжки, да и статьи, по программированию описывают синатксис, функции, ну.. некторые приемы.. Но как это все слить воедино? Я знаю что такое рекурсия! Но, ёлки-палки! Я никак не могу врубиться, куда же ее засунуть?
Или вот пример: работа над ошибками. Никак не могу понять, как профи это делают. В том же CI чуть не большинство функций вообще ничего не возвращают кроме кода ошибки. Как так?!? А для чего вообще нужны эти функции? Но ведь работает же, зараза! И как! Для меня это тайна за семью печатями... А как научиться? Что читать? В чем секрет? Вот, собственно мой вопрос к вам, Мэтры!
ой, JustUserR, а растолкуйте пожалуйста, в чем разница между addslashes() и mysql_real_escape_string() ? Все почему-то рекомендуют вторую, а мне нравится первая (ввиду того, что все наставленные ею слеши потом можно легко убрать с помощью stripslashes())
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 40
Да и диски будет забивать влет.
Посмотреть на код профи приятно - например на код фреймворка (я пользовался CodeIgniter) - он напоминает аккуратную кирпичную кладку стены дома в маленьком альпийском городке. Мой же код напоминает приведенную ниже картинку. И речь идет не о том, чтобы соблюдать отступы и правильно расставлять скобки, одинаково расставлять горбы в названиях переменных и классов. Этому я более-менее научился. Речь об общей логике написания программ.
