Рациональность структуры БД

[idencial]

Рациональность структуры БД

Ситуация состоит в следующем:

Необх. реализовать простенькую систему рассылки.

При этом конечно рассылок может быть много, а потому я делаю отдельную таблицу.

CREATE TABLE maillist_kind (
maillist_id int(3) NOT NULL auto_increment,
maillist_name text NOT NULL,
PRIMARY KEY (maillist_id)
)

Помимо этого необходимо есно хранить адреса подписантов и чтобы было ясно на какие конкретно рассылки они подписаны.

Для этого я делаю следующую таблицу:

CREATE TABLE maillist (
maillist_id int(3) NOT NULL default '0',
email tinytext NOT NULL,
subscriber_name tinytext NOT NULL
)

Соотв. количество одинаковых e-mail подписанта говорит о количестве рассылко на которые он подписан.

Что можите сказать относительно второй таблицы. Может можно как-то рациональнее?
Я вообще прочитал, что такой способ годиться, если количество полей не больше 15.

 

[C.H.]

Ага, а если у тебя будет 1000 пользователей, и каждый будет подписан на кучю рассылок??? Дублирование е-майлов и имен!
Лучше заведи справочник польщователей и во второй таблице в место е-майла и имени пиши номер пользователя:

CREATE TABLE maillist (
maillist_id int(3) NOT NULL default '0',
user_id int(3) NOT NULL default '0',
);

CREATE TABLE user (
user_id int(3) NOT NULL auto_increment,
email tinytext NOT NULL,
subscriber_name tinytext NOT NULL
PRIMARY KEY (user_id)
)

 

[AnToXa]

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

 

[idencial]

Спасибо. Есть еще доп. вопрос. ПОсоветуйте какое поле добавить во вторую таблицу, чтобы можно было подписывать на html формат письма и на простой текст.
Идиально подошло бы здесь 0 и 1 (html или нет).
Какая альтернатива в MySQL полю boolean (ведь как я знаю MySQL не поддерживает логич. поля)

 

[AnToXa]

сделать справочник с типом поля и один-ко-многим в него из таблицы рассылок

 

[AlexM]

Какая альтернатива в MySQL полю boolean (ведь как я знаю MySQL не поддерживает логич. поля)

ENUM

 

[AnToXa]

ENUM

нееет... только не enum это ужасное поле... просто ужасное
не надо его.

 

[idencial]

а какое надо?

 

[AnToXa]

на 2 сообщения выше читал?
это мой совет

 

[idencial]

Я про альтернативу логич. полю в Мускуле, а не про структуру.
С ней я уже все решил.

 

[su1d]

tinyint unsigned not null

 

[si]

а чем ENUM так не нравиться ?

 

[Сытник]

Автор оригинала: si
а чем ENUM так не нравиться ?

наверное потому что в нем буква 'я' не работает

 

[AnToXa]

[si]:
1. невозможно получить список всех допустимых значений
2. невозможно добавлять новые значения без alter table

это уже огромные недостатки, а о скорости работы я бы еще поспорил и побенчил

 

[tony2001]

ну список можно =)
DESC table
хотя, конечно, это не самый удобный вариант.

 

[AnToXa]

tony2001: мы на канале это помнишь обсуждали
ага... сравни один запрос с парсингом строки... руский человек славится своим умением находить ВХОД в трудные ситуации

 

[idencial]

Спасибо за ответы, но, наверное остановлюсь на tinyint

 

[tony2001]

>tony2001: мы на канале это помнишь обсуждали
да помню
я ж сам это и делал.
я просто хочу сказать, что это возможно, причем без особых усилий.
однако "удобным" это никак не назовешь.

 

[AnToXa]

вот именно.

 

[AlexM]

2AnToXa
Я сам юзаю tiny, однако думал что ENUM работает быстрее...
Что-то нигде не мог найти инфы про бысродействие ENUM.
Не подскажешь?