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

Mal Hack
в самой mysql у пользователей Y и N

Пока вы далеко не зашли!

Есле вы используете базу!
Тогда лучше есле статья будет в виде файла а ссылка храниться в базе на нее.
Тогда мы облегчим вес базы.
Как такой вариант?



Я уже работаю в полуручном варианте.
Админ еще не готов.

Проблемы были с защищеным режимом сервера.
Пришлось темы и разделы создавать в базе и генерить ссылку на файл.
Каталог с файлами придется защищать.

Мое мнение.
Пока

Спасибо, интересно.
А далеко мы не зашли потому что никто не пишет...по теме по крайней мере

Хы ) после написания регистрации пришло время вернутся к написанию данного скрипта - статей.

Опик, хочу извенится за все свои посты - прочитал их сейчас и ужаснулся. Понял как многово я тогда не знал и откровенно тупил 

Итак, регистрация у меня теперь есть. Она у меня с форума IPB.

Новый план: таблицы статей, таблица комментариев, таблица групп, таблица категорий. 

Aliance, 
я сейчас тоже почитал - улыбнуло , причем мои же больше всего.


скидывай дамп  посмотрим структуру ))))) 

Пример 1 еще неодобренной статьи с 1 комментарием:


Вот. Логин и группа будет братся из другой БД, она уже готова (БД форума IPB)
Пока возникают такие вопросы:
• что-то сделано не так?
• поля content заданы как varchar(255) - хватит ли этого? Если статья может быть на страницу. Может лучше BIGBLOB использовать?
• если вся статья скрыта, то на "скрытость" комментов должно быть все равно. Реально ли?
• не понимаю особого назначения 3 таблицы    

Это сообщение отредактировал(а) Aliance - 17.5.2006, 21:40

Aliance, ну во-первых, я бы вынес авторов в отдельную таблицу и связывал бы по id-ишникам, т.к. это у тебя сечас избыточная информация, затем, мне не понятно для чего это поле

имеет текстовый тип. Я так понимаю, оно должно иметь связь по id-ишнику с третьей таблице section.

в таблице `articals` тоже не уместно.
Поля дат, я бы перевел в тип INT(10) и загонял бы туда дату в формате unix-timestamp.
Таблица `articals_comments` - я вообще не вижу как она связана с основной таблицей статей, должно быть поле articleID, которое будет содержать ссылку на своего родителя, т.е. на статью.
Поля content я бы сделал тип TEXT. 

Я бы сделал так:
 

А я бы сделал как -=Ustas=-, но в том отличии, что поле content с типом TEXT вынес бы в отдельную таблицу и связал по ID
 

Так будет оптимальней? 

-=Ustas=-, 
Да, т.к для поля BLOB, TEXT не поддерживаются таблицами HEAP, грубо говоря выборка из таблиц, содержащих TEXT, BLOB идет при помощи файлов.

Добавлено @ 17:56 
А не в памяти, как у остальных, но тут много нюансов по сути есть. 

Ээ, а если так оставить? Мне так понятнее, во-первых. Во-вторых, зачем мне авторов в отдельную таблицу выносить-то? 

Можно  , если ты над собой издеваться любишь


Вот именно, это только ВО-ПЕРВЫХ, а далее ты будешь смотреть на эту структуру и сам с себя улыбаться.


В твоем подходе, это называется избыточной информацией. Смотри, создал ты 50 статей, в итоге у тебя получается 50 строк с 50-ью никами Aliance. А вдруг ты захотел поменять свой ник - тут тебе придется править его в 50-строках, вместо того, чтоб исправить в одном месте.
Это не рационально, использовать подобную структуру. 

Aliance, 
Есть понятнее, а есть правильнее и логичее, что потом, в итоге, станет понятнее первого.

Что лучше выбрать?