UsikСлушай дружище,

Ув. Usik - не злите пожалуйсто нашего гостя... Он тааакой неутерпимый в гневе... Пжста - не нада. Это к тому что говорит наш Ув guest_20040621 - правильно. Для начала рассмотрите каждую сущность на предмет ее нормализации. Например:

параметрические показатели одного человека меняются со временем. То есть вес Naroto в начале года был 110 lb а сегодня Naroto объелось и весит уже 150 lb но вот оно возьмётся за себя и станет худеть и опять станет 110 lb. То же и с ростом. Naroto уже старенькое и сгорбливаецца. Было 6 ft теперь вот 5 ft 10 in. Или вот Курит - не курит... Naroto давно не курило.. :) Но это же не видно... Ну и так далее. То есть представьте что для описания параметров одного человека по имени Naroto вам потребуецца 150 записей в течение одного года. И каждое по 25 полей. Это ж ваша база не выдержит описания всего что присходит с Naroto за достаточно короткий период времени. (1 год){Нет ну выдержит канешно - но не в этом суть}

А посему - почитайте теорию и увидите что для нормализации базы Вам понадобится упростить все Ваши сущности. Развести их по полочкам:
ЧЕЛОВЕК
у самого человека для записи в книге актов рождения будут как бы только {извините за медицинские термины}:

То есть наберём и больше если захотим - и что? То есть вот так всё записано когда родилось Naroto.. А теперь:



То есть ваш ЧЕЛОВЕК если разобраться будет с теми же 25 полями в которые будут вбиты его текущие аттибуты на данное время, год назад, неделю назад и так далее. Определитесь с минимально необходимым набором неизменных данных определяющим сущность на какой то период времени. это и будет уровнем грануляции вашей системы. Количество полей ограничивается только параметрами системы. Naroto понятно изложило?

Usik Я апдэйтнул запись, и все. Дак откуда появится 150 записей на этого Ивана? Вот чего непонд я.

Вы совершенно правы для такого сценария (и если не нужно исторических данных) всё что нужно "на данный момент" - именно так и делают. Но к сожалению базы данных не для этого существуют. Они хранят информацию длительное время и управляют ею. Смотрите - данные роддома о рождении ЧЕЛОВЕКА где то зарегистрированы и не могут быть изменены. Никогда. это запрещено законом. Если родился белый мальчик - вы не можете изменить его на чёрную девочку, ведь так?

динамические же изменения по времени, по цене, по жизни, по чему угодно - да конечно существуют и в зависимости от задач их можно вносить в базу данных а можно и обойтись. Понимаете о чём Naroto ? как пример - Вам инересно в какой цвет были покрашены Башни Близнецы в течение всего времени существования этих зданий? Если нет - зачем хранить эту информацию в базе? А если да?

Пример Naroto привело не простой.. Башни Близнецы сгорели. Нашлась всего одна компания в мире которая установила причину и указала возможный путь предотварщения пожара. Догадываетесь откуда они это узнали? Знаете какой путь был предложен?

Кстати о количестве полей описывающих сущность - из того же примера про Башни - Там было всё таааак денормализовано что просто кашмар. То есть понадобилось много времени чтобы построить правильную версию из бардака который использовали загружая данные в три десятка таблиц по 180 полей каждое. А если нормализовать то ответ получится сразу - тока посмотри.. :)

guest_20040621Naroto, взялись объяснять - не пишите фигни

Ув guest_20040621 ... Спасибо за напоминание... Но Naroto очень просит Вас держать себя в руках ... Naroto благодарило... Ко всему Naroto ничего не объясняло, Naroto рассуждало... Вслух....

Для Топик Стартера. Темпоральность - это зависимость от времени. Действительно - никакой зависимости нет. Naroto привело эту зависимость за неимением ничего лучшего. Сама идея Реляционных Баз Данных - они Относительны. (От слова Relation - Отношение). Суть же любых Баз данных - обеспечение Хранения данных длительное (относительно) время а не их динамические изменения. Это более философская тема чем научная. Надеюсь Naroto доступно объяснило {без сложных терминов}?

alexeyvgНу и вообще, может, для данной задачи лучьше иметь таблицу объекта и таблицы атрибутов...
Предела усовершенствования уже существующего ХОРОШЕГО - нет. Да и ЛУЧШЕЕ враг ХОРОШЕГО. Naroto очень рекомендовало бы топик стартеру почитать Аз и Буки и Веди и Гаммы проектирования баз. Как это было предложено в весьма положительной {относительно конечно На взгляд Naroto} форме Ув. guest_20040621. Конечно всё зависит от задачи. Конкретний задачи. И как предмет для ее решения - если Вы не знаете что делать с базой данных - не используйте ее и всё. В Большинстве оперативных задач базы данных просто никчему.

guest_20040621Вы, Naroto, слишком многословны ....
Не судите да не судимы будете... Уважаемый... Naroto ещё раз поблагодарило Вас, Ув. guest_20040621 за сдержанность.

теперь о вашей Задаче Топик Стартер. Задача ставится просто - Ваш сайт - сайт объявлений. Сущность его - контент. это один текстовый филд. Выбирать пользователь будет по:


Вроде все Ваши сущности преведены. Разбивка или деталировка по компонентам обычно для вашей системы не требуется. Достаточно сделать единый текстовый филд в котором можно или не обязательно вносить все более детальные параметры системы.

Например Naroto {kak сказал ув гость} многословно. С чем это связано? Оно - это балбес из Отдела Продаж Носков фирмы Адидас. Но у нее есть три стареньких машины. Оно понятия не имеет что там внутри. А хотело продать. Всё что надо - поместить объяву. То есть - цена, место, как называецца, фото.... и всё. Не так ли?
Пример такой системы в реальной жизни посмотрите тут:
Если будут более детальные вопросы - задавайте. Naroto откланяло...