[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: зависимость таблиц
Гость_lex
Доюрого времени суток. Сразу к делу сайт мнргр пользовательский. Зарегистрированные пользователи пишут статьи. Как лучше увязать таблицу пользователй с таблицей статей. Т.е.

№1

автор статья

id id

login nazvanie

id statei


№2

автор статья

id id

login nazvanie

id автора







Спустя 4 минуты, 5 секунд (4.12.2009 - 09:40) Гость_lex написал(а):
немного коряво получилось объясню на словах т.е. в таблице авторов ввести поле id статей, или же в поле статей ввести привязку к id автора, или можно сгрупировать как то еще?

Спустя 13 минут, 21 секунда (4.12.2009 - 09:53) Chudik написал(а):
Цитата
или же в поле статей ввести привязку к id автора

только не в поле статей, а в таблице статей должна біть колонка id_автора, вот по ней и будет осуществляться привязка и автора к статьи и статьи к автору

Спустя 7 минут, 55 секунд (4.12.2009 - 10:01) Гость_lex написал(а):
угу я вот просто думаю, если таблица очень большой от окнтента получиться и пользователей к ней то же большой колчиество будет обращаться сайт подвисать не начнет может 3 таблицу поставить привязок именно т.е. (ID автор - ID его статей) или загоняюсь?

Спустя 43 секунды (4.12.2009 - 10:02) Гость_lex написал(а):
и вообще может как то иначе это все далаеться, как правильнее сделать?

Спустя 12 минут, 57 секунд (4.12.2009 - 10:15) Chudik написал(а):
ну если у тебя будет так что одна статья, а кней нужно привязать несколько авторов то нужно делать третью доп. таблицу, в другом случаэ это будет только мешать, на скорости работы это поле не скажется

Спустя 32 минуты, 25 секунд (4.12.2009 - 10:47) Ka4_0k написал(а):
Лучше сделать как ты написал в первом посте мне кажется. А потом просто джоинить. Просто так у тебя будет отдельно список авторов и список статей. Тоесть при управлении можно сделать и управление авторами (переименование, изменение) и другим контентом, и это будет намного проще. Нпример смотри, структура такая:
1 Таблица

author_id | author_name
1 Вася

2 Таблица

note_id | note_text(статья)
1 Текст статьи

3 Таблица - таблица связи (соответствия)

note_id | author_id
1 1

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

Спустя 1 час, 1 минута, 5 секунд (4.12.2009 - 11:48) Гость_lex написал(а):
Хм, Ka4_0k,
а пример опций можешь привести которые могут применяться?


С вашего разрешения я усложню задачу допустим у нас три типа стаетй по рубрикам кино музыка игры опять таки как лучше поступить просто все в одной таблице разместить или 3 разные сделать?

Спустя 2 часа, 24 минуты, 33 секунды (4.12.2009 - 14:13) Chudik написал(а):
Цитата
а пример опций можешь привести которые могут применяться?
Можно будет присвоить одной статье несколько авторов.

Если ты собираешся статью публиковать в нескольких рубриках, то тогда придется делать связную таблицу id_post | id_rubrika если статья будет публиковаться только в одну рубрику, будет достаточно и добавить поле rubrika в таблицу со статьями.

Спустя 1 день, 12 часов, 16 минут, 13 секунд (6.12.2009 - 02:29) Гость_lex написал(а):
хм спасибо

Спустя 8 минут, 13 секунд (6.12.2009 - 02:37) Гость_lex написал(а):
ребят знаю, что не втой части форума вопрос задаю, но тем неменее что бы не бегать по темам, спрошу здесь. Как лучше поступить для оптимизации, для скорости загрузки, скорости работы скриптов и объемов памяти на сервере - вот такие критерии получаються, если есть еще какие то не упомянутые -укажите если не трудно, вопрос вот в чем- пользователи могут заносить изображения на сайт, при этом программно генериться сразу два : обрезанное, для просомтра, и миниатюра, для афиши так сказать, как лучше сделать- создать одну папку под картинки или для картинок отдельного пользователя по отдельной папке ? так жэе на разные группы контента - о ильмах , о играх, и т.п. разные папки под изображения созлдавать или ограничеться одной?
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.