Интересует то, в каком направлении копать для создания форума. Задача, конечно сложная, но плох тот солдат... Итак, меня интересует организация данных в MySQL. Можно к примеру из каждой темы делать таблицу, а названия тем и разделов также размещать в отдельной таблице, а можно все поместить в одну таблицу и делать выборку по названию темы(что нужно будет отобразить в отдельной колонке), к тому же еще где-то читал на форуме, что хорошо сделать таблицу, описывающую тех пользователей, кто в данный момент находится на сайте для более быстрого доступа и т.д. Просветите, плиз, как лучше организовать структуру, какие есть подводные камни, как их избежать?
Лучше для начала посмотреть готовые движки форумов На мой взгляд, у vBulletin довольно грамотно спроектированы таблицы.
Dagdamor дело в том, что я только начал освоение мускула, поэтому просто заблужусь в том коде, поэтому и создал тему. К тому же может кто поделится эксклюзивными идеями
BAnder Для этого не обязательно копаться в коде. Поставь у себя форум, понасоздавай пробных категорий, тем и сообщений, после чего открой phpMyAdmin и посмотри таблицы, как называются поля, какие в них хранятся данные. Код тебе в любом случае придется писать свой.
Горбунов Олег Угх... статья про Conditional Get меня убила. Где можно высказать по данному поводу, чтобы не было оффтопиком?
Vladson темку почитал, интересно, хотя многое не понятно. В общем сейчас по теме интересует только одно: организация системы иерархии в предполагаемом форуме. Т.е. хотелось бы, что б вся иерархия (разделы, подразделы нескольких порядков, темы) была заключена в БД, но пока не представляю как это осуществимо. Понимаю, что за меня никто это делать не будет, но надеюсь, что хотя бы подскажете в каком направлении копать. Я ж пока не про все возможности мускула и пхп знаю.
В том-же топике я давал ссылку http://dev.mysql.com/tech-resources/art ... -data.html почитайте и её тоже (именно про иерархию, хоть и на английском, но английского там мало, больше кода, по этому понятно даже без знания английского)
Наконец-то понял о каком nested шла речь В общем, в плане иерархии выбор сделан. Теперь еще вопрос, как лучше хранить информацию о времени: в одном столбце с использованием datetime или в 2х (date и time). Собственно проблема не в том что б создать одну или 2 колонки, а в возможности из вариант datetime вычленить нужную часть. Можно ли этого добиться средствами MySQL или PHP (в PHP уверен что можно, но тут встает вопрос целесообразности). Ну и еще один нюанс: одна ячейка времени в формате datetime занимает 8 байт, в то время как если ее разделить на 2 составные - 7 байт, это получается выбор между быстродействием и занимаемым объемом базой данных(думаю, что чаще придется использовать вариант datetime)? ЗЫ. Что-то я разошелся... Надеюсь никакие вопросы не потеряются
Я всегда стараюсь хранить дату/время как INT (таймстамп, но не мускульный). Очень уж удобно с ним работать потом. А для вывода таких штампов на экран добавил пару функций в шаблонизатор, и все.
Спасибо, думаю, что datetime - то что надо. Хотя всегда интересно услышать аргументированное другое мнение А у меня между тем возник еще один вопрос Что будет работать быстрее (ну и по возможности на сколько), несколько вложенных запросов или дополнительная колонка в БД размером эдак байта 2 на строку? Ясное дело, что многое будет зависеть от частоты запросов, поэтому предлагаю принять среднее значение обращаемости(в крайних случаях и так ясно что к чему) ЗЫ. Наверняка у каждого разное понимание значения слова "среднее", прошу учесть
armadillo А где я говорил что он удобнее? Но не будем придираться к словам: 1) валидация и приведение проще 2) все операции - арифметические 3) легче превратить в читабельный вид, если надо что-то типа "1 января 2008" 4) от типа БД не зависит, к примеру в Оракле типа DATETIME просто нет 5) (для BAnder'а) меньше места занимает (4 байта вместо 8, бугога).
что есть «немускульный» таймстамп я такого не говорил. Тип есть. Просто дату он возращает в зависимости от локали сервера.
Горбунов Олег Я смотрел в доках. Нет там такого типа. Есть только DATE. Таймстамп в поле с типом INT (т.е. не обычный TIMESTAMP).
Горбунов Олег Это разные типы совсем. Просто случайно называются одинаково TIMESTAMP вернет что-то типа 20080101120000, INT - нормальное число, количество секунд с такого-то момента. Плюс TIMESTAMP автоматически обновляется. В общем с ним я бы не советовал иметь дело И все же типа DATETIME в Оракле нет. Это минус (нужно подгонять запросы). Да и возвращает он результат в каком-то хитром виде, не в стандартном.
Dagdamor Имея поле типа int с таймстампами, попробуй сделать какие-нить калькуляции с датами на уровне чистого SQL.... К примеру сделай мне запрос, где твой int сработает нормально для такого (это ещё примитивный вариант, который при помощи PHP довольно легко делается, а вот если чисто силами SQL с int... ЫЫЫЫ): [SQL]WHERE to_days(datetimefield) = to_days(now())[/sql]