Форумы портала PHP.SU » Разное » Колонка администратора » Новый форум. Структура базы. Конвертор

Страниц (3): [1] 2 3 »
 

1. RomAndry - 24 Декабря, 2014 - 11:15:11 - перейти к сообщению
Приветствую. Думаю стоит начать обсуждать структуру форума.
Первый этап и параллельно я бы начал делать конвертер из файлов.
У кого какие мысли и предложения?
2. Мелкий - 24 Декабря, 2014 - 11:25:00 - перейти к сообщению
RomAndry пишет:
конвертер из файлов.

Можно попросить актуальный код и пару файлов на поиграться?
Или код хранения данных не менялся и достаточно расковырять дистрибьютив ExBB FM 1.0 RC1? (кстати, его обновляли без смены номера версии, последний раз, насколько вижу, 15.07.2009)

По новой структуре я пока жду обновление репозитория. Имеющиеся наработки по форуму DeepVarvar'ом вроде бы ещё не опубликованы.
3. DeepVarvar - 24 Декабря, 2014 - 11:54:35 - перейти к сообщению
Не опубликованы - я застрял на обвязке пользака (вход, выход, рега, форгот).
Но могу быстренько пойти на сближение залив тупо базовую структуру БД и контроллеры+шаблоны вывода.
Сделать?
4. Мелкий - 24 Декабря, 2014 - 12:33:29 - перейти к сообщению
Хороший вопрос.
Мне пока хватит и только базовой структуры - расковырять имеющиеся файлы и соображать что куда писать надо.
5. DeepVarvar - 24 Декабря, 2014 - 13:12:55 - перейти к сообщению
Готово. Лежит в репо.
А еще вопрос - почему дата время регистрации пользака в CURRENT_TIMESTAMP ?
Всмысле зачем в таймстампе?
6. Мелкий - 24 Декабря, 2014 - 13:30:34 - перейти к сообщению
0) потому что умеет default CURRENT_TIMESTAMP (datetime научился этому только в 5.6). Зачем заполнять данные по-умолчанию на приложении, если это может сделать СУБД?
1) за предстоящие 20 лет ещё много раз всё поменяется, форум будет заменён ещё раза 3, а mysql вообще загнётся
2) компактнее в два раза
7. DeepVarvar - 24 Декабря, 2014 - 13:56:00 - перейти к сообщению
А это не повлияет на:

1) сравнения,
2) сортировку,
3) форматирование при выборке дат/времен,
4) часовой пояс установленный через SET time_zone = '+03:00'

?
8. Мелкий - 24 Декабря, 2014 - 14:09:10 - перейти к сообщению
1-3) нет, date, datetime и timestamp - очень близкие родственники.
4) зависит от. таймштамп хранится всегда в UTC и обращает внимание на time_zone, в отличии от datetime. Если записать что-то в timestamp, изменить таймзону и прочитать обратно - строковое значение будет другое. Но если пересчитать в изначальную таймзону - то идентичное.
9. DeepVarvar - 24 Декабря, 2014 - 14:22:36 - перейти к сообщению
Мелкий пишет:
в отличии от datetime
Хмм, а я вот проверял - работало. Версия 5.1.73-1
В любом случае убедил, т.к. либо ты вычитал в доках, либо руками напоролся на касяк с таймзонами в datetime, но таймстамп будет работать везде.

Исправь тогда, плиз, остальные datetime поля во всех табличках.
Заодно глянешь может еще где-то касяк есть.
10. Мелкий - 24 Декабря, 2014 - 14:55:15 - перейти к сообщению
Да, это из доков:
http://dev[dot]mysql[dot]com/doc/refman/[dot][dot][dot]en/datetime[dot]html
Цитата:
MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.)

Возможно мы с мануалом друг друга не поняли. По работе для простоты и кода и персонала работаем только в московском времени, так что может datetime и обращает внимание на таймзону.
11. DeepVarvar - 24 Декабря, 2014 - 15:31:03 - перейти к сообщению
Продолжим тут отдельно про БД.

Есть такой вопрос.
Предполагается куча всякой всячины прикручивать к пользакам, ака личные настройки.
Сейчас точно известно, будет (некоторые даже уже есть) - аватар, галочки оповещений, часовой пояс, кол-во постов на страницу, etc.
Что-то я подумал, может вынести эту шелуху в отдельную таблицу без автоинкремента, но с уникальной привязкой к основной таблице?
12. Panoptik - 24 Декабря, 2014 - 15:58:11 - перейти к сообщению
я бы подобные данные сохранял в формате таблицы
user_id, setting, val
где пара user_id, setting - есть уникальна или первичный ключ,а в setting хранится некоторый ключ сеттинга, все сеттинги изначально декларируются гдето и если такового сеттинга не найдено в бд то он берется из дефолтного значения, а после изменения последнего сохраняется в эту таблицу

собственно вариант очень гибкий и не завтавляет редактировать таблицу при возникновении новой идеи (тут же можно хранить и такие интересные вещи как последняя просмотренная страница или последнее значение введенное пользователем в поиск и всякие другие удобствоприносящие фичи)
13. DeepVarvar - 24 Декабря, 2014 - 16:07:29 - перейти к сообщению
В этой идее смущает только поле val - потому как хрен его знает, какого типа и какой длины значение ты туда запишешь. А может индекс понадобится пробросить еще.
14. Panoptik - 24 Декабря, 2014 - 16:21:48 - перейти к сообщению
ну суть этого поля носить значение, а искать как раз по ключевому полю
те значения по которым предполагается искать должны быть в других таблицах и соответствующих им полях. а в данном случае text
15. DeepVarvar - 24 Декабря, 2014 - 16:33:05 - перейти к сообщению
Panoptik пишет:
а в данном случае text
Я именно про него.
Смысл писать в текст значение '1' только лишь для включения оповещения чего-то там на мыло. А дефолт как выставлять? А выборку как? А условия? Кастовать?

 

Powered by ExBB FM 1.0 RC1