Несколько таблиц с общими полями(Навеяно темой Дата записи MySql)
Вот с чего все начиналось
Я бы вобще сделал 3 таблицы.
1 - с общими данными
две другие имеют данные свойственны каждой из сущосностей. и связал их по ПК.
Это сразу дает возможность без каких либо потерь и головной боли расширить сущонсть в будущем. Например, нужно будет ввести автора статьи, или еще что-то
2Lone Wolf Без этого тоже замечательно делается)) Можешь создать топик - обсудим или в личку.
Цитата: Lone Wolf
Я бы вобще сделал 3 таблицы.
1 - с общими данными
две другие имеют данные свойственны каждой из сущосностей. и связал их по ПК.
Это сразу дает возможность без каких либо потерь и головной боли расширить сущонсть в будущем. Например, нужно будет ввести автора статьи, или еще что-то
Цитата: shaelf
С общими это лишнии джоины))) По мне лучше 2 таблицы разные. Вообще, когда я писал CMSку (как давно это было), которую потом неоднократно использовал, то у всех таблиц были 3 служебных поля (кстати это очень удобно, хоть и добавляет избыточность) это __id, __createDate, __modifyDate.
Цитата: Lone Wolf
Да join-ы лишнии есть, но зато если надо реализоывать систему комментов, или еще чего-то где свзка 1-ко-многим, то наоборот уменьшает кол-во таблиц или полей.
а про поля created_at и modificated_at, эт да - удобно. Я щас на symfony+doctrine пишу проэкт, так тут вобще в схеме задется деректива и ОРМ сама генерит эти поля и сама их заполняет
а про поля created_at и modificated_at, эт да - удобно. Я щас на symfony+doctrine пишу проэкт, так тут вобще в схеме задется деректива и ОРМ сама генерит эти поля и сама их заполняет
Цитата: shaelf
2Lone Wolf Без этого тоже замечательно делается)) Можешь создать топик - обсудим или в личку.
Допустим такая ситуация. (Упрощу немного в моем случае таблицы другие и у каждой собственных полей больше).
Есть 3 таблицы. Новость, Статья, Фотография
Общее у таблиц это Автор(ФК ключ), Город(ФК ключ), Название, Текст
Собственное, Новость - дата. Статья - категория(ФК), Фотография - пусть будут координаты.
К каждой сущности подвязываются комментарии и тэги.
Я выносил общие даные в одну таблицу и для каждой сущности создавал свои с собственными поялми.
Плюсы что я вижу, Нету пустых не использываных полей в таблицах если делать одну большую.
Легче подвязывавть коментарии и тэги. Подвзязываются к одной таблице(случай 3х абсолютно разных таблиц)
Минус - много JOIN-ов.
А теперь интерестна альтарнатива. как можно было бы сделать прощею
P.S. Создал тему, так как думаю не только мне будет такое интерестно
Есть 3 таблицы. Новость, Статья, Фотография
Общее у таблиц это Автор(ФК ключ), Город(ФК ключ), Название, Текст
Собственное, Новость - дата. Статья - категория(ФК), Фотография - пусть будут координаты.
К каждой сущности подвязываются комментарии и тэги.
Я выносил общие даные в одну таблицу и для каждой сущности создавал свои с собственными поялми.
Плюсы что я вижу, Нету пустых не использываных полей в таблицах если делать одну большую.
Легче подвязывавть коментарии и тэги. Подвзязываются к одной таблице(случай 3х абсолютно разных таблиц)
Минус - много JOIN-ов.
А теперь интерестна альтарнатива. как можно было бы сделать прощею
P.S. Создал тему, так как думаю не только мне будет такое интерестно
В общем смотри. Если ты работаешь с какой нить ОРМ, то можешь использовать (скорее всего там оно есть) наследование на уровне языка программирования, но не б.д. (вечером подробнее отпишусь). Ещё в качестве минуса это скорость. Т.е. чем не больше таблица, тем она медленней, это факт. В даном случае ты пихаешь туда фактически 3 сущности. Если проект небольшой и хочется абстракции, то советую сделать таблицу link(childId, parentId, childName, parentName). В твоём случае там будет link(12, 45, news, comment); Думаю понятно)) Тогда ты реально сможешь привязывать что угодно к чему угодно, при этом сами таблицы об этом знать не будут )).
Цитата: shaelf
Если проект небольшой и хочется абстракции, то советую сделать таблицу link(childId, parentId, childName, parentName). В твоём случае там будет link(12, 45, news, comment); Думаю понятно)) Тогда ты реально сможешь привязывать что угодно к чему угодно, при этом сами таблицы об этом знать не будут )).
Хм. Вариант
Но получается для выбора всех комментов к конкретной сущности нуже JOIN
И в случае удаления сущности, прийдется руками перебирать. таблицу link для удаления всех комментов.. Конечно это не сложно, но все же..
Аналогично при удалении коммента.
также parentName и childName и нужно либо Enum-ом делать, либо где-то хардокидить их перечень.. но это скорее для удобства..
И еще один момент. Я использую symfony+Doctrine(1.2)
Все запросы(большинство) пишуться на ее собственом языке DQL и все джоины делаются через алиасы, о которых знает только Доктрина.
Т.е. Для без проблемной выборки всех комментов для конкретной новости нужна явная связка по ФК...
А в случае такой таблицы прийдется либо писать кастомный запрос, что не очень удобно, потому что на выходе получить модель будет невозможно(будет просто масив данных) либо делать несколько запросов. Сперва вытьянуть все ИДшники комментов, а потом вытягивать сам комменты, что тоже сомнительное удовольствие.
Не нужны никакие енумы)) Ты просто вставляешь туда имя таблицы. Т.е. допустим у тебя есть таблицы CommentTable и NewsTable, тогда там будет (1, 10, NewsTable, CommentTable). Конечно, если ты привязан к какому-то определённому ОРМ, то тогда нужно следовать его идеологии ))
про Enum я не то хотел сказать, я просто предпочитаю как-то ограничивать значения таких, полей. Также часто удобнее работать с цифровими константами.. но то дело случая.
В моём случае это не так. Просто 1 таблица = 1 класс (модель) и там хранились именно имена классов. Хотя, имя класса = имя таблицы :)
PS Как рабочий вариант (вне CMS) я так же рассматривал вариант вынесения сущностей, который 100% будут потомками (например те же комменты) и делать у них 2 доп поля - entityName, entityId.
PS Как рабочий вариант (вне CMS) я так же рассматривал вариант вынесения сущностей, который 100% будут потомками (например те же комменты) и делать у них 2 доп поля - entityName, entityId.
та много где так.. это конечно удобно в контексте PHP 5.3
получил имя класса с БД, вбил в переменную и используешь ее в виде $class->get('field'), ну или как там в ОРМке твоей.
У меня введение ENUM-а в похожей ситуации было нужно для сфинкса. тип записи был атрибутом при поиске.
Хотя потом вычитал про sql_attr_str2ordinal вроде им можно было обойтись..
получил имя класса с БД, вбил в переменную и используешь ее в виде $class->get('field'), ну или как там в ОРМке твоей.
У меня введение ENUM-а в похожей ситуации было нужно для сфинкса. тип записи был атрибутом при поиске.
Хотя потом вычитал про sql_attr_str2ordinal вроде им можно было обойтись..
Ура, я дома и могу писать :). Как обычно больше в оффтоп ухожу, но думаю, что интересный. При написании такой структуры идея была разбить запросы на несколько мелки (т.е. джоинов не было вообще). Смысл был в том, что я фактически работал только с линковочной таблицей, а всё остальное было в кеше с ключами вида tableName . entityId (например News12) и только оттуда забиралось. Укладывалось туда при записи в БД, стиралось при удалении из бд, обновлялось при изменении. Фактически (в 95%) работа с бд сводила к
SELECT childId FROM __links WHERE parentId = 12 AND parentName = 'News' AND childName = 'Comment'
Этим самым я получал id всех комментов к новости и мне нужно было всего лишь выдернуть их из кеша. Для средних и небольших проектов на мой взгляд это идиальная система (на больших возникает проблема с линковочной таблице, она хоть и узкая, но высокая получается и начинает всё притормаживать, хоть кеш на уровне вьюх спасает конечно). А вообще реально гибко и красиво :)) Самое главное, что это ооочень легко поддерживается :)))
SELECT childId FROM __links WHERE parentId = 12 AND parentName = 'News' AND childName = 'Comment'
Этим самым я получал id всех комментов к новости и мне нужно было всего лишь выдернуть их из кеша. Для средних и небольших проектов на мой взгляд это идиальная система (на больших возникает проблема с линковочной таблице, она хоть и узкая, но высокая получается и начинает всё притормаживать, хоть кеш на уровне вьюх спасает конечно). А вообще реально гибко и красиво :)) Самое главное, что это ооочень легко поддерживается :)))
Согласен. Идея шикараная, и за нее тебе большой респект.
Единственное что
Единственное что
Цитата: shaelf
Конечно, если ты привязан к какому-то определённому ОРМ, то тогда нужно следовать его идеологии ))
Но даже в данном случае можно попытатся извернутся. Безвыходных ситуаций не бывает.
Ну там обычно такие извращения наказываются)) У меня реально всё решалось в одном небольшом классе (примерно на 250 - 300 строк) :)
Оч красиво! Только практики визуальной надо, не понимаю я когда все красиво написано, тоесть гдето глубоко в душе понимаю, но гдето уж оч глубоко :)
А можно еще глупый вопрос? Линковочная таблица - это что? Это термин, или это реальная таблица?
(не пинайте сильно)
А можно еще глупый вопрос? Линковочная таблица - это что? Это термин, или это реальная таблица?
(не пинайте сильно)
Реальная таблица, в ней хранятся отношения родителей к потомкам.
на примере то, что в моих таблицах id, parent_id, это вынесено в отдельную таблицу?
я Вам в icq постучал
я Вам в icq постучал
Просто пришло много иероглифов, за спам принял).
Да, именно так + имена табли (в моём случае), но можно и на каждое отношение свою таблицу.
Да, именно так + имена табли (в моём случае), но можно и на каждое отношение свою таблицу.
Цитата: Lone Wolf
Минус - много JOIN-ов.
А что собственно плохого в join'ах ? Мне наоборот говорили, что join намного лучше и опреративнее в работе, чем таблица с кучей полупустых полей?
Или есть подводные камни? (Сложность запроса не считается)
Тебе точно про mysql говорили?:) Просто может я отстал от жизни, но в мускуле есть несколько тормозов:
1. join
2 LIKE %string%
3. вложенный запрос
1. join
2 LIKE %string%
3. вложенный запрос