phpMyAdmin 2.7

можно нескромный вопрос, а нафиг он нужен?

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

ну а с триггерами-вьюхами можно и самостоятельно разобраться...

для хостеров катит. чтобы юзверям не заморачиватса слишком

>можно нескромный вопрос, а нафиг он нужен?

За тем же, зачем нужен MC при наличии shell. Удалённо рулить БД не тупо делая запросы, а одним взглядом окидывая кучу данных, для улучшения интуитивного восприятия и упрощения ряда работ.

Незаменимый инструмент.

>особенно в свете того, что mysql не держит даже ссылочную целостность

Так ты уж определись, тебе непонятно зачем нужен phpMyAdmin, непонятно зачем нужен mysql, или так, потрындеть просто...

не, имхо такой инструмент нужен когда есть необходимость разобраться в монструозных таблицах. А если эти таблицы еще и ссылаются друг на друга - тогда ессно разобраться в этом хаосе становится все труднее.

но я в мускуле редко видел БД размером больше 20-30 таблиц (если не счиать клинических случаев типа phpnuke)

если неправ - поправь. Лучше с примерами =))

> но я в мускуле редко видел БД размером больше 20-30 таблиц (если не счиать клинических случаев типа phpnuke)

Большее количество таблиц встречается, например drupal - 52 таблицы по дефолту.

С phpMyAdmin проблема в том, что он не очень стабилен, и кодировку в нем трудно настроить, чтобы она совпадала с установленной в MySQL.

странно у меня почемуто все автоматом подцеплялось и с кодировкой НИРАЗУ пробелм не было.

не, нуегонафик.

почему мне для форума достаточно 5 таблиц (и то одну выкинуть можно в принципе), а у них для CMS не хватает пусть даже 20, а надо обязательно чтобы было не меньше 50?

офигеть ваще...

> особенно в свете того, что mysql не держит даже ссылочную целостность (не кричать про InnoDB, вчера специально проверял).


поподробнее, пожалуйста (это не праздный интерес).

по моему для форума достаточно 2-х таблиц. Пользователи и Сообщения. Ну и Сессии если хранить их в базе

не, у меня так:

CREATE TABLE groups (
gid tinyint(3) unsigned NOT NULL auto_increment COMMENT 'номер группы',
gname varchar(50) NOT NULL default '' COMMENT 'название',
gabout tinytext COMMENT 'дополнительная информация',
PRIMARY KEY (gid)
) ENGINE=MyISAM DEFAULT CHARSET=koi8r;

CREATE TABLE messages (
mid int(10) unsigned NOT NULL auto_increment COMMENT 'номер сообщения',
mdel enum('y','n') NOT NULL default 'n' COMMENT 'удаленное или нет',
mname varchar(100) default NULL COMMENT 'название',
mtext mediumblob NOT NULL COMMENT 'текст',
mtid int(11) NOT NULL default '0' COMMENT 'номер темы, в котором находится',
mauthor int(11) NOT NULL default '0' COMMENT 'номер автора',
mdate timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP COMMENT 'время добавления',
PRIMARY KEY (mid)
) ENGINE=MyISAM DEFAULT CHARSET=koi8r;

CREATE TABLE moders (
muid int(11) NOT NULL default '0' COMMENT 'номер пользователя',
mgid int(11) NOT NULL default '0' COMMENT 'номер группы',
mact enum('y','n') NOT NULL default 'y' COMMENT 'активен ли. Сделано для избежания провалов в ключах',
PRIMARY KEY (muid,mgid)
) ENGINE=MyISAM DEFAULT CHARSET=koi8r;

CREATE TABLE themes (
tid int(11) NOT NULL auto_increment COMMENT 'номер темы',
tdel enum('y','n') NOT NULL default 'n' COMMENT 'удалена или нет',
tname varchar(100) NOT NULL default '' COMMENT 'название',
ttext mediumblob NOT NULL COMMENT 'текст',
tgroup int(11) NOT NULL default '0' COMMENT 'номер группы, где находится тема',
tauthor int(11) NOT NULL default '0' COMMENT 'автор',
tdate timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP COMMENT 'время добавления',
PRIMARY KEY (tid)
) ENGINE=MyISAM DEFAULT CHARSET=koi8r;

CREATE TABLE users (
uid smallint(5) unsigned NOT NULL auto_increment COMMENT 'номер юзера',
ulogin varchar(20) NOT NULL default '' COMMENT 'логин',
upass varchar(23) NOT NULL default '' COMMENT 'пароль',
uname varchar(50) NOT NULL default '' COMMENT 'имя',
uinfo tinyblob COMMENT 'дополнительная информация',
ucity varchar(20) default NULL COMMENT 'город, где находится',
ucountry varchar(20) default NULL COMMENT 'страна',
uicq varchar(12) default NULL COMMENT 'номер аськи. Надо будет сделать номер для жаббера',
ugender enum('f','m') default NULL COMMENT 'пол юзера. в принципе необязательное поле, но пусть будет',
uemail varchar(50) default NULL COMMENT 'мыло юзера. must be for password recovery',
utoor enum('y','n') NOT NULL default 'n' COMMENT 'админ или нет. надо будет что-то сделать, ибо инфа дублируется, даже спец. таблица moders есть...',
ubanned enum('y','n') NOT NULL default 'n' COMMENT 'забанен или нет',
PRIMARY KEY (uid)
) ENGINE=MyISAM DEFAULT CHARSET=koi8r;

З.Ы. там еще есть таблица fortunes, с фортунками, но она необязательна.

З.З.Ы. ну и как я говорил, таблицу moders можно выкинуть по причине наличия utoor флага в users.

Чего б тогда одной таблицей не обойтись? Сообщения и всё. Зачем еще что-то? :)

а можно вообще без таблиц, просто на бумажечке писать фразы и друг другу пересылать почтой =)))

Как на счет категорий (групп тем), аттачей к сообщениям, внутренней переписки, прав доступа?

категории есть, таблица groups.

остальное пока справедливо относится к рюшечкам и в реализации стоит даже не на втором месте.

первым делом надо бы кукисы сделать и сесии =))

Да, не разглядел... Группы юзеров, значить, тоже рюшечки? :)

блин, оно все не о что в бете, а глубочайшей жо^H^Hальфе.

так что работы еще - море.

Я делал не так, но у меня была задача создать гибкий форум, с произвольным числом тем/уровней, и с "цепочками" сообщений, поэтому пришлось извратиться, и обойтись двумя таблицами :-)

themes/messages - по сути вещи одного порядка и объединяются в одну таблицу, в каждой записи хранятся ссылки на "голову", предыдущее сообщение (а для эффективности и на все связанный с ним - одно из полей хранит список ИД связанных сообщений)

групп пользователей правда у меня нет - есть категории админ/moder/user определены через enum

только что ради интереса зашёл на phpMyAdmin нашего портала и глянул сколько таблиц в базе, которая прикрученная к нашей CMS... 116 таблиц ;) и 236406 записей всего...

и это нормально?

это 3,1415926535897932384626433здец просто...

как ты сделал линк на вышестоящее?

и как у тебя темы отличаются от сообщений? тем, что в них ссылки на самих себя присутсвуют?

>одно из полей хранит список ИД связанных сообщений

массивом делал? разве мыскль допускает массивы?

2 gr_buza: так как выяснилось, что mysql не держит зависимости?

есть поле "типа" сообщения (enum) - хранит по сути "уровень" - название темы, подтемы, под-под темы, собственно сообщение и т/д - в зависимости от того, сколько уровней надо.

дополнительно, указатель на "голову" принимает значение NULL если оно и есть "голова"

массивов в MySQL, увы, нету, поэтому приходится делать два запроса - вытаскивать поле со списком IDs, затем следующим запросом вытаскивать сами записи через WHERE id IN(IDs). Но по производительности очень неплохо получается.

p.s. это мои ответы вверху...

В нашей CMS - 52 таблицы. И это - фигня. У каждого сервиса - свои таблицы. У кого 1, у кого и 20. А сервисов у нас - кот наплакал. Что за членомерка вообще, количеством таблиц мерятся? Их должно быть столько, сколько нужно. Соблюдая принцип KISS, само собой...

дык о KISS и речь...

а вот кто может подсказать элегантное решение такой задачи. Есть несколько "деревьев" сообщений. Надо выводить количество сообщений в каждой "ветке" и подветке дерева и БЫСТРО обновлять их динамически при добавлении сообщений в любое место дерева. Рекурсивный обход дерева каждый раз слишком тяжел. Хранение IDs всех связанных веток в каждой ветке и их подсчет не подходит - поскольку есть несколько деревьев. Еще варианты?

mysql> create database reftest;
Query OK, 1 row affected (0.00 sec)

mysql> use reftest;
Database changed
mysql> create table refmaster (
-> mid int not null primary key auto_increment,
-> mname varchar(20) not null) type=innodb;
Query OK, 0 rows affected (0.16 sec)

mysql> create table refslave (
-> sid int not null,
-> stext tinytext not null,
-> foreign key (sid) references refmaster(mid)) type=innodb;
ERROR 1005: Can't create table './reftest/refslave.frm' (errno: 150)
mysql> create table refslave (
-> sid int not null references refmadter(mid),
-> stext tinytext not null) type=innodb;
Query OK, 0 rows affected (0.03 sec)

mysql> insert into refmaster values ("","hi");
Query OK, 1 row affected (0.01 sec)

mysql> insert into refslave values ("5","hello");
Query OK, 1 row affected (0.01 sec)

mysql>

это ссылочная целостность?

или может я не так делаю что-то?

З.Ы. по идее он дожен во втором инсерте заорать благим матом, что нет такого индекса, ан хрен...

массивы есть в ЯП :)

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

SELECT MAX( id ) FROM table WHERE parrent_id == x

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

каунт - да.

только есть одно но: при включенном auto_increment индексы идут дальше, как ни в чем ни бывало. И мы имеем таблицу из 10 строк, в ней одну грохают (десятую) и добавляют строки дальше - получается 8,9,11,12,etc.

соответственно каунт на такой хрени выдаст несоответствие.

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

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

/me в ужосе...

> SELECT MAX( id ) FROM table WHERE parrent_id == x
id в разных ветках дерева расположены не последовательно
SELECT COUNT(*) FROM table WHERE parrent_id == x
- вот это бы подошло, но это еще медленнее чем рекурсивный обход всего дерева и собирания "статистики" со всех веток вместе.

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

может триггер бы подошел, который при добавлении сообщения увеличивает счетчик на 1?

> id в разных ветках дерева расположены не последовательно

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

Надо же, проблемы с киррилицей до сих пор остались, mysql 4.1.14 c 2.6 версии в русских записях - каша. DEFAULT_CHARSET koi8-r, со всеми остальными клиентами проблем нет.

А не знает ли кто под линукс приличного аналога EMS MySQL Manager? ИМХО лучший в своем классе инструмент, хоть и платный.

дык задача то - собрать число "веток" в каждом поддереве. Решается "в лоб" через рекурсивный COUNT всех веток лежащий "ниже"и сохранения этого COUNT в записи каждой ветки как счетчик ( обновлять его только при добавлении нового сообщения). Но и это тяжело. Надо легче решение.

живой пример того, чего надо сделать. Идем на ebay.com и смотрим, как реализованы "счетчики" количества лотов в категориях, подкатегориях и т.д При добавлении нового лота, счетчик лотов во всех связанных категориях увеличивается на 1. Это реализуемо.
Но. Если добавлена запись для города А, то при просмотре категорий для города Б счетчик не должен измениться. И вот для этого я пока не нашел хорошего решения...

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

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

каунт у меня делается только один раз в начале и при добавлении/удалении целой ветки. Все остальное - +1(-1 при удалении) для счетчиков в зависимых категориях

> SELECT MAX( id ) FROM table WHERE parrent_id == x

убивать надо умников, которые пытаются заниматься вычислениями авто-инкрементных полей! я уже зае...я разгребать дерьмо после студентов, наклепавших всякие "select * from record where id=:some_id-3"

>по моему для форума достаточно 2-х таблиц

Достаточно. Но для скорости желательно по таблице на 1 раздел. И таблицу под блоуировки IP.

А тебе всегда нужна ссылочная целостность? Мне вот - совсем далеко не всегда, и в таких случаях я беру MySQL.

Да, а ещё еть phpPgAdmin, роццтвенник сабжа.

>но я в мускуле редко видел БД размером больше 20-30 таблиц (если не счиать клинических случаев типа phpnuke)

а по 200-300 таблиц слабо? Они ещё и динамически создаются и дропаются))

товарищи! читайте как деревья в базе хранить, чтобы без рекурсии их вытаскивать....

> товарищи! читайте как деревья в базе хранить, чтобы без рекурсии их вытаскивать....
с удовольствием прочитаю, а ссылочкой нельзя поделиться?

Мля, надоел этот ПЫХПЫХ! Даешь java!

>массивы есть в ЯП

мы не ищем легких путей? (с)

субд не поддерживающая такого

http://www.postgresql.org/docs/8.1/static/arrays.html

достойна топки