Хранение документов разной структуры

_RVK_

Новичок
Не, ты смешал логику приложения и модель данных. Лично мы говорим только о структуре БД. Как эти данные потом используются в приложении это уже отдельный разговор. У меня то же какждое поле таблицы это объект, но причем здесь это? Так что давай говорить исключительно о структуре БД, а то как с ней потом работать, это уже дело десятое.
да, только без проблем сортировки, поиска и выборки по полям
Опа, поясни. Чем твой вариант отличается от первого, что сразу исчезают такие проблеммы.
 

vitus

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

Опа, - поясню :) :
Я ведь говорил о комбинации вариантов 1 и 2, не так ли?

Она отличается от варианта 1 индексом, организованым в соответствии с вариантом 2.

поиск, сортировка, выборка ссылок на целые объекты - по варианту 2

подъём объекта из базы - по варианту 1.

сохранение - в три этапа
 

_RVK_

Новичок
Итак, насколько я тебя понял таблица с данными все же существует, но используется только для целей поиска. В основной же таблице хранится серелизованный объект, для того что бы при выборках не дергать вторую таблицу. Так?
Вообще то насторавживает наличие избыточности данных, хотя признаю, что такой способ избавлен от недостатков первого и второго варианта.

А теперь сравним твой гибрид с третьим вариантом. Я по прежнему считаю, что его недостаток только в реализации. К стожалению проект, где мне нужно было хранить документы разной структуры загнулся, а то бы я выбрал бы именно 3-й вариант.

У меня вообще такое чувство что само упоминание об использовании запростов ALTER, CREATE, DROP и т.д. вызывает подсознательный ужас у многих. И только по этой причине выбирается второй вариант, а иногда и первый.
 

vitus

мимо проходил
Originally posted by _RVK_
Вообще то насторавживает наличие избыточности данных...
:) google - не настораживает? он индексирует интернет - представь - какая избыточность!


А теперь сравним твой гибрид ...
:) это не мой гибрид, так внутри устроено много чего полезного, практически все реляционные базы данных в частности.


У меня вообще такое чувство что само упоминание об использовании запростов ALTER, CREATE, DROP и т.д. вызывает подсознательный ужас у многих. И только по этой причине выбирается второй вариант, а иногда и первый.
вполне сознательный ужас - это не то что дыра в безопасности, - это прямой путь на помойку.
 

_RVK_

Новичок
google - не настораживает
Ну и сравнение! :) Ладно, я вижу что достоинства такой схемы перевешивают недостатки.
вполне сознательный ужас - это не то что дыра в безопасности, - это прямой путь на помойку
Подробнее. Где дыра? Я вообщем-то и создад этут тему что бы обсудить грабли третьего варианта решения. Я пока еще нигде не встречал определение БД как статической сущности. Почему структура БД не может быть динамической с непостоянным числом таблиц и меняющимися связями?
 

vitus

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

Несмотря ни на какие презумпции невиновности.
 

_RVK_

Новичок
Тебе лучше озаботиться аргументированным доказательством отсутствия дыр
так я не знаю чего здесь аргументировать. откуда могут быть дыры? понятно что про sql-ижекшен я в курсе. не говоря уже о том что абы кто к CMS не допускается.
Мне кажется насчет дыр ты погорячился. Я такой проблемы не вижу.
 

Screjet

Новичок
А почему бы не использовать классический подход?
Изначально узнаешь все возможные типы данных,= неиспользумые поля по дефолту NUL, главная таблица еще содержит инфу для дерева, в реляционных: списки/справочники (1-М,М-М).

зы. Всякая Супергибкость очень сильно снижает рентабельность разработки (увеличивается сложность/время разрабокти/стоимость, и уменьшается производительность).
 

3BEP

Новичок
_RVK_

У меня вообще такое чувство что само упоминание об использовании запростов ALTER, CREATE, DROP и т.д. вызывает подсознательный ужас у многих. И только по этой причине выбирается второй вариант, а иногда и первый.
Подсознательный ужас вызывается комментариями более опытных товарищей ;-) К сожалению эти комментарии зачастую не содержат пояснений почему - только утверждения. Попытаюсь прояснить некоторые почему

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

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

В третьих, кроме структурных изменений, при ALTER, CREATE, DROP и т.д. приходится поддерживать еще и целостность прав доступа. На этом пункте мне хочется остановиться поподробнее.
Как известно (если кому-то неизвестно - читайте документацию к MySql) для доступа к серверу базы данных необходим логин и пароль. Эти параметры используются для определения прав доступа - которые определяют, какие действия разрешены конкретному пользователю. К сожалению, многие используют всего один аккаунт с максимальными правами - что не есть хорошо :) Хотя MySql позволяет очень тонко ограничить права - вплоть до запрета на просмотр/обновление/вставку нескольких полей отдельной таблицы, при полном доступе к другим полям.
Применение этих ограничений может спасти от написания сотен строк кода, защищающего от sql-инъекций, разгрузить сервер - ведь при использовании аккаунта с ограниченными правами на просмотр можно упростить проверку входных данных (естественно, необходим и аккаунт с более широкими правами при использовании которого проверка производится в полном объеме)
 

_RVK_

Новичок
3BEP
Первые 2 "почему" подпадают под сложность реализации, о которой я говорил. Последний пункт.... не обижайся, но ИМХО высосан из пальца. Хотя бы потому что права GRAND тебе врятли кто даст в большенстве случаев. А если даст, то и динамически менять права это вообще не проблемма.

Вообще жаль что проект деградировал до травиальной задачи. Теперь этот топик для меня превратился в чисто теоритический.
 

3BEP

Новичок
_RVK_

Первые 2 "почему" я не описывал подробно как раз потому что это подпадает под сложность реализации. А вот последний пункт - практически нигде не упоминается именно в плане защиты.
А с управлением правами... Мне как правило помогает письмо в саппорт хостера, в котором я прошу понизить права некоторых аккаунтов MySql (оставить только SELECT для определенных таблиц - все остальное запретить, например). И GRANT мне не нужен. Мнение о хостере, саппорт которого не считает нужным позаботится о защите клиента можно не высказывать?
И естественно, изменения структуры базы данных, для которой есть несколько аккаунтов с разными правами и нет возможности динамически управлять этими самыми правами становится достаточно долгим и сложным процессом. Хотя это по крайней мере заставляет как следует подумать что менять и зачем до внесения изменений. ;)
 
Сверху