Проект «Humor.Filtered Online»

Alexey Zelkin, ph@sunbay-software.com:

«К этому можно добавить:
1. анализ статистики сервера на предмет выявления самых читаемых авторов, то есть сделать что-то вроде Top10 :)
2. голосование читателей — их собственная оценка письма (что то подобное вроде сделано на anekdot.ru )
3. Я думаю все-таки не нужно исключать Subj из базы. Иногда возникают ситуации, когда «клиент» помнит сабж, но не помнит всё остальное. То есть идея в том, чтоб оставить сабж, но не для того, чтоб отображать, а для улучшения возможностей поиска в базе.
4. Однотабличная структура — это «малопроизводительный пережиток прошлого», остатки FOX'a, CLIPER'a и т. д. Но не буду вдаваться в теорию. Идея следующая: вместо строчных полей типа DIGEST, AUTHTOR_NAME, должны быть использованы связки (или как их там называют) primary-foreign key. В случае DIGEST'a например всё выглядит так: создаётся таблица DIGEST с полями PKEY и NAME. В неё вставляются данные типа: pkey = 1, name = «hf» etc. После этого в таблице писем создаётся поле DIGEST не строка, а число. И в это поле вставляется не строка «hf», а просто значение 1. И когда программе понадобится значение этого поля (строковое), она просто должна обратится к таблице DIGEST и выбрать row со значением pkey = 1. Как то смутно описал, но надеюсь понятно что я имел ввиду. Этот метод имеет массу преимуществ по сравнению с предложенным тобой. Преимущества в основном заключаются в том, что размер базы будет _значительно_ меньше при том же наполнении, скорость поиска гораздо выше, система становится гораздо меньше зависима от последующих изменений.

Моё видение структуры базы (предварительное):

Таблицы:

Писем (таб. LETTER):

PKEY — primary key, собственно
MSGID — message id
PUBLICATION_DATE — дата публикации
SEND_DATE — дата посылки
DIGEST — дайжест (foreign key для таб. DIGEST)
SOURCE_ECHO — исходная эха (возможно тоже foreign key, в — случае частого повторения одной и той же эхи)
AUTHOR — автор (foregin key для таб. AUTHOR)
SUBJ — тема
TEXT — текст

COMMENT — комментарий (печаталось где-либо etc.)

Дайжестов (таб. DIGEST):

PKEY — primary key
NAME — имя дайжеста

Авторов (таб. AUTHOR):

PKEY — primary key
NAME — ФИО автора
ADDR — адрес (мейл)

В таблицу типов писем я думаю всё-таки нужно добавить и название типа :-)»

Koctya Boyko 03 Nov 1998:
в общем, сегодня я засунул в sql все 15 архивов с hfo.kru.to и сделал простейшую мордочку для просмотра — с одной единственной кнопкой «стрелка вправо». Сейчас обеспечиваю возможность просматривать базу не только с моей машины, но и извне. Следующий шаг — классификация имеющихся месаг (+отлов дупов, +редактирование). Это самый трудоёмкий участок — по оптимистичным оценкам от 100-150 человеко-дней и более... Соответственно, нужно порядка 30 волонтёров на эту работу (с тем, чтобы каждому досталось порядка 500 сообщений). Я хочу попробовать реализовать всё через web-интерфейс — кнопки и менюшки на нём делаются несложно. Работать можно как через интернет, так и на локальной машине... Далее, все куски работы собираются воедино и производится завершающая шлифовка — 2-3 человека, 15-20 человеко-дней. После чего я готовлю к передаче базу и инструкции по её установке.
Сейчас в базе — одна таблица msgwin (1251) со следующими полями id — уникальный идентификатор, присваивается сообщению при начальном заносе в базу
fromname — кто отфорвардил
fromaddr
toname — как правило, это all :)
subj
body — текст
kludges — служебная информация

от идеи использовать msgid пришлось отказаться, так как во многих ранних форвардах его нету.
В дальнейшем информация этой таблицы будет использована для построения нескольких таблиц меньшего размера (примерно как предлагает Alexey Zelkin), а сама она останется только как некая «точка опоры», все запросы будут идти к её «потомкам».