Например надо сделать блог с категориями. Реализовать это можно несколькими способами.
Можно создать две таблицы:
1. категории
cat_id int(11) auto_increment
category varchar(100) UNIQUE
2. записи блога
text_id int(11) auto_increment
….
category_id int(11)
В первой хранить список категорий, во второй записи блога и каждую запись связывать с какой либо категорией через числовой идентификатор (category_id = cat_id).
Но может возникнуть проблема: если пользователь удалит катекорию в которой есть записи, а потом передумает и создаст новую категорию с тем же именем, то все будет выглядеть как было, но связи категории с записями уже не будет. Можно конечно сделать так что категории могут помечаться как удаленные а потом восстанавливаться, когда пользователь создает категорию с таким же именем. Но можно сделать проще.
category_id int(11)
заменить на
category_name varchar(100)
Связать таблицы через текстовые поля.
Тогда после удаления и создания категории с тем же именем связь с записями блога будет восстанавливаться.
Хотя можно сделать еще проще: удалить таблицу категорий, их имена будут храниться в таблице записей блога в поле category_name.
%)
22 августа 2009 в 0:05
Когда планируеш базу:
1 Реши что без чего не может сушествовать?
К примеру: сообщение не может существоват без автора (кто-то же его написал). Автор может сушествовать без сообщения (он еще думает чтонаписать). Отсюда все вытекает само собой: связь таблиц( автор ко многим сообщениям), автора нельзя удалить пока у него есть сообщения.
2 своди NULLы к минимуму. Так ты сам того неподозревая достигнеш третьей нормальной формы.
к примеру: есть таблица "заказов" в ней поля "дата заказа" и "дата готовности".
"дата готовности" заказа будет содержатьNULL до момента вывоза заказа.
от этого нужно избавиться. Нужно сделать таблицу "готовые заказы".
и вней будетполе"дата готовности" таким образом в таблице "готовые заказы" нет строки до факта вывоза заказа. и в таблице"заказов" нет поля с NULL.
Это кажется лишней заморочкой, но это залог гибкости и успеха базы даных.
А еще, чел выше дело глаголит!
21 августа 2009 в 21:00
если одна запись = одна категория, то первый вариант с двумя таблицами и запрет на удаление непустых категорий
если одна запись = много разных категорий, тогда три таблицы:
1) категории, 2) тексты записей блога, 3) связь текстов и категорий
ИМХО второй вариант с тремя таблицами решит 99% проблем.
21 августа 2009 в 14:01
Карочь думаю этого хватит:
Есть отдельная таблица категорий. Посты можно удалять, категории нет. Когда юзер приписывает свой пост к категории, он пишет в комбобоксе начало категории и получает выпадающий список категорий, начинающихся с такого имени, соответственно он выбирет в любом случае категорию с правильным ИД и новую не создаст.
Зачем такую кривизну сочинять, когда можно одним контролом обойтись, пусть и возможно самописным.
21 августа 2009 в 13:03
Вообще если планируется восстанавливать категории с тем же именем, то лучшее решение их физически не удалять. Это даст постоянный ИД не только в базе но и в ссылках. А в программе уже сделать обработку и удаленные категории и посты к ним показывать только через корзину. Если кто то хочет создать категорию сименем удаленной – отфутболивать в корзину и предлагать либо восстановить со всеми постами либо менять имя. Имя будет изменяться без проблем т.к. связь по ИД.
21 августа 2009 в 11:00
#8 — возможно. Но обрати внимание на первое слово первого поста. Мне кажется, что аффтар просто тренируется, и ему не важна коммерческая ценность проекта.
21 августа 2009 в 11:00
#9ну если тренируется, то смею предложить ему избавиться от второй таблицы с категориями, дав пользователям свободный выбор категорий
21 августа 2009 в 10:05
тогда уж сделай "корзину". чтоб при удалении сначала в нее все уходило.
смысла делать связь по текстовым полям нету вообще.
если будет в блоге тысяч категорий и десятки тысяч постов и много посетителей, то у тебя мускуль-сервер сляжет напрочь…
21 августа 2009 в 10:05
#2 Действительно, хотя это на усмотрение автора
#1 А вообще, если удаляется категория, то записи либо удаляться должны, либо должен быть запрет на удаление непустой категории, либо зануление ссылки на категорию. В любом случае, кроме запрета, связь будет утеряна. Внешний ключ как констрэйнт, должен заботиться о целостности. Нельзя указывать на то, чего нет.
21 августа 2009 в 10:05
Marina Jee
Запись может соответсвовать нескольким категориям, например одна категория насущная, типа " компы", а вторая филосовская, типа "непознанное" или "для размышления"
21 августа 2009 в 10:05
#3 +1, по текстовым не стоит связку делать.
21 августа 2009 в 10:05
#5 — автор, похоже,подразумевает всецелую и неделимую принадлежность записи к категории. А в таком контексте #2 права.
21 августа 2009 в 10:05
#7 но это савсем неудобно и не гибко. Да и вообще не нужно))) да и второй таблицы там не нужно
21 августа 2009 в 10:04
Честно сказать не вижу смысла оставлять записи, если удалена категория