всем привет [img]images/smiles/icon_smile.gif[/img]

собираюсь создать таблицу в которой будет :
<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">code:</font><HR><pre>
CREATE TABLE data (
id INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (id),
text BLOB
)
</pre><HR></BLOCKQUOTE>
вот и всё …
а вот и дилема - знаю, что запховывать в туды буду как 10 символов в строку, так и 10кб текста в следующюю, причём в произвольном порядке и количестве.
есть ли это хорошо, или это есть плохо ?
и лучше сделать сравнительно примерно-одно-длинно-текстовые таблицы ?

трудно что-либо посоветовать - информации о предполагаемой БД через чур мало (структура, назначение, ожидаемые запросы и нагрузка, соотношение чтение/запись, и т.д.)

теоретически в одной таблице должны храниться однородные данные, чего не скажешь о 10 символах и 10кб.

Что мешает написать программку на любимом языке на пол-экрана и просто экспериментально проверить? [img]images/smiles/icon_smile.gif[/img]

Oleg Fomin
значит назначение:
делаю административный пакет, типа phpnuke .
в этой таблице собирается храниться текст со всего сайта, будь то вопрос на голосование, или здоровеннейшая рецензия.
на различных языках.
(3 минимум - русский, английский, иврит - этот - вообще трабла ходячая)
требования - не глючить сильно … [img]images/smiles/icon_smile.gif[/img]
будет поиск по LIKE, но по конкретным ID - тем, которые релевантны.
что то типа - SELECT text FROM data,categories WHERE category.data_id=data.id AND data.text LIKE '%sale%';
поэтому проблем с излишними сверками текстов не должно быть.
записи намного меньше чем запросов.
то есть, один раз инсерт, и неделю - селект [img]images/smiles/icon_smile.gif[/img]

Crazy
только одно - не знаю на что тестить [img]images/smiles/icon_smile.gif[/img]
на скорость ли, или на полный выпад в осадок при совершенно сумасшедших соотношениях строк …
типа -
1 byte
1 MB
1 byte
1 MB
1 byte
1 MB
1 byte
1 MB
1 byte
1 MB
итд - и глянуть что с ним станет ….
но это глупо - не умрёт же …. [img]images/smiles/icon_smile.gif[/img]
так что просто, подозреваю, как Oleg Fomin что теоретически - это не совсем правильно.

[ 03 Января 2002: Исправлено Intelligent ]

Crazy, на полэкрана не прокатит, точнее может и прокатит, но только не программа написанная за 15 минут.

Бенчи, как одна из методик оценки эффективности бд - штука хорошая. только вот сымитировать реальные условия работы (размер, состояние, кластеризация, статистика запросов и т.д.) довольно тяжело. тут еще такой минус, что в mysql довольно примтивные средства оценки эффективности, в отличие скажем от оракла.

на маленькой бд различия в структуре и в запросах ничтожны. но для больших баз они могут быть существенны и притом нарастать с логарифмической скоростью.

если бд предполагается небольшая - делай как хочешь.
если предполагается большой объем и загрузка - надо думать.
этим вещам вообще-то в универах учат. 5 лет подряд... [img]images/smiles/icon_rolleyes.gif[/img]

Насколько я понимаю, "LIKE '%foobar%'" -- это уже гарантированное полное сканирование таблицы. Соответственно если хочется ускорить процесс, то данные с разными data.id стОит вынести в отдельные таблицы. Соответственно при N вариантах data.id и равномерном распределении (как по id, так и по длинам) ты получишь ускорение в N раз.

Или тебе не ускорение нужно?

Oleg Fomin
если бд предполагается небольшая - делай как хочешь
а вот не знаю … вероятно - 20 мб не перевалит …
этим вещам вообще-то в универах учат. 5 лет подряд
да знаю я … знаю …
сам отучился не мало … но и не 5 и не в универе …
а 6 и в спец-школе … по бабам правда больше бегал , но аттестат получил [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote:</font><HR>Автор Сообщения Oleg Fomin:
<STRONG>Crazy, на полэкрана не прокатит, точнее может и прокатит, но только не программа написанная за 15 минут.

Бенчи, как одна из методик оценки эффективности бд - штука хорошая. только вот сымитировать реальные условия работы (размер, состояние, кластеризация, статистика запросов и т.д.) довольно тяжело.</STRONG><HR></BLOCKQUOTE>

Собственно, автор указал конкретную проблему, соответственно если проверять именно ее, то 15 минут на написание теста хватит.

Ну а в общем случае -- это да, обращение к серьезному специалисту, неделя времени и пара штук баксов. [img]roof.gif[/img]

Crazy
а кому оно не нужно ?! [img]images/smiles/icon_smile.gif[/img] [img]images/smiles/icon_smile.gif[/img] [img]images/smiles/icon_smile.gif[/img]
мне правда тормоза сильнее не нужны … [img]images/smiles/icon_wink.gif[/img]

но механизм этого запроса ведь не будет сверять всю data ?
<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">code:</font><HR><pre>
SELECT text
FROM data,categories
WHERE category.data_id=data.id
AND data.text LIKE '%sale%';
</pre><HR></BLOCKQUOTE>

Intelligent, ууу блинский-блин. как все запущено.

1. в книге по mySQL что-то встречал относительно выборок по полям типа blob - какие-то характерные особенности. вспомню - найду.

2. что такое пхпнюк - не ведаю, но если количество коротких полей сопоставимо с количеством длинных, то может иметь смысл отдельная таблица.

Crazy
а что сверять то ?!
у меня нет проблем накатать _любой_ сложности тест …
но что он будет проверять ?!
сколько "слезло" ?
какова разница между обычной индексацией и этой ?
сколько места теряется ?
что сверять то ?

Oleg Fomin
по идее - количество коротких преобладает раза в 4-5 над длинными.
но их "короткость" тоже разная : от 10-ти до 120-ти символов.

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote:</font><HR>Автор Сообщения Intelligent:
<STRONG>
но механизм этого запроса ведь не будет сверять всю data ?
<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">code:</font><HR><pre>
SELECT text
FROM data,categories
WHERE category.data_id=data.id
AND data.text LIKE '%sale%';
</pre><HR></BLOCKQUOTE></STRONG><HR></BLOCKQUOTE>

По-уму -- не должен (если есть индекс по id и сервер захочет его использовать). Но де факто я иногда ловил это счастье (но, признаться, не с MySQL).

На мой взгляд все же проще разнести по таблицам, благо код запросов не обязательно строить руками.

Crazy
ну что … 2 таблицы ?
( а сервер НЕ будет проверять ВСЁ … и БУДЕТ юзать индексы )

Трудно активно общаться на форуме, где не строится дерево ответов... [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote:</font><HR>Автор Сообщения Intelligent:
<STRONG>Crazy
а что сверять то ?!
у меня нет проблем накатать _любой_ сложности тест …
но что он будет проверять ?!
сколько "слезло" ?
какова разница между обычной индексацией и этой ?
сколько места теряется ?
что сверять то ?</STRONG><HR></BLOCKQUOTE>

Ты примерно знаешь частотные характеристики своих данных. Берешь пару книжек с www.lib.ru, нарезаешь из них случайным образом текстовые куски в соответствии с требуемыми частотными характеристиками и пихаешь в базу до нужного объема.

Потом выдаешь запросы и видишь, тормозит ли оно.

относительно такой же базы, но с бОльшим количеством таблиц ?
по скорости ?
вот такой вот бенч ?
оки, щя, сек [img]images/smiles/icon_smile.gif[/img])

Intelligent, опять таки я не слишком хорошо предсталяю картину, но судя по тому что ты говоришь, лучше длинные поля вынести в отдельную таблицу. причем организовать остальную структуру так, чтоб перед началом select было известно в какой таблице искать - т.е. не перелопачивать сначала короткие а потом длиныые записи (не знаю возможно ли это у тебя). иначе особого толку в разделении не будет.

Oleg Fomin
именно так.
я точно знаю в каких строках/таблицах искать.
хотя сек, разговор только про поиск ?
всё остальное - ОК ?

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote:</font><HR>Автор Сообщения Intelligent:
<STRONG>относительно такой же базы, но с бОльшим количеством таблиц ?
по скорости ?
вот такой вот бенч ?
оки, щя, сек [img]images/smiles/icon_smile.gif[/img])</STRONG><HR></BLOCKQUOTE>

Кратко: вариант с несколькими таблицами будет не медленее варианта с единой наблицей.

А теперь -- небольшой комментарий относительно того, почему я считаю нужным экспериментальный тест.

1. Для единой таблицы.

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

2. Для нескольких таблиц.

против) большая сложность в реализации
за) можно разрешить простой table scan, который будет более эффективен, чем сканирование с фильтровкой по индексам в предыдущем случае.

Что в большей степени "сыграет" на результат можно проверить только экспериментально.

Я бы начал в варианта с одной таблицей и если полученная скорость будет достаточна -- на этом и остановился бы.

Ок , уболтали [img]images/smiles/icon_smile.gif[/img]
спасибо [img]images/smiles/icon_smile.gif[/img]
будет возможность в следующей версии увеличить скорость поиска [img]images/smiles/icon_smile.gif[/img]
теперь бы не забыть где кость зарыта [img]images/smiles/icon_smile.gif[/img]