|
|
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Нужно хранить данные о контрагентах. Часть атрибутов (например название, адрес, телефон) - существует всегда, но также нужно дать возможность пользователю (администратору системы) определять свой набор атрибутов для контрагента. Два варианта: 1. Постоянные атрибуты хранить все вместе в одной таблице, где каждый атрибут - столбец. Для пользовательских атрибутов определить две таблицы: перечень_атрибутов(id,название_атрибута); данные(контрагент_id,атрибут_id,данные); 2. Абсолютно все атрибуты хранить в двух вышеуказанных таблицах. В первом случае невозможно одним нормальным запросом (без извратов) выбрать все атрибуты. Зато во втором случае сложнее делать запросы с выборкой по нескольким атрибутам. Как это сделано у вас или как бы вы это сделали ?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2005, 20:22 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Будут ли осуществлятся выборки по атрибутам которые сделал пользователь? Если нет, то вполне может хватить поля "Примечание". Пусть пишут туда все, что хотят. Если да, то я применяю способ 1. Проблемы с "разворачиванием" по горизонтали решаю на клиенте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2005, 21:15 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Cat2Будут ли осуществлятся выборки по атрибутам которые сделал пользователь? Если нет, то вполне может хватить поля "Примечание". Пусть пишут туда все, что хотят. Нет, одно поле точно не катит. Дело в том, что по данным из таблицы контрагенты создается документ с реквизитами контрагента. Суть создания документа в том, что имя атрибута вида %[Количество_машин]% заменяется на значение этого атрибута у конкретного контрагента. Кроме того, в далеком будущем планирую сделать создание пользовательских фильтров для выборки, в том числе, по пользовательским атрибутам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2005, 22:34 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich Anton Количество атрибутов - конечно. Не лучше ли на этапе проектирования выявит ВСЕ нужные атрибуты и занести в таблицу полями? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2005, 22:43 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Cat2Ugnich Anton Количество атрибутов - конечно. Не лучше ли на этапе проектирования выявит ВСЕ нужные атрибуты и занести в таблицу полями? Ха ! :) Если бы все было так просто, я бы не спрашивал. Система пишется не под конкретного заказчика и даже не под какую-либо отрасль промышленности/народного хозяйства. Поэтому я никак не могу знать, какие атрибуты может захотеть добавить пользователь (админ) системы. Все-таки больше склоняюсь ко второму варианту, потому как все атрибуты хранятся по единому образу и подобию. Что же касается сложности выборки по многим атрибутам, то эту проблему прийдется решать так или иначе. А там уже одним атрибутом больше, одним меньше... Как считаете ? Можно согласиться ?! :) З.Ы. Маленький анонс: все труды по этой теме собираюсь выложить в открытом виде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2005, 23:10 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich Anton . Ну Вы замахнулись ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2005, 00:00 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Cat2Ugnich Anton . Ну Вы замахнулись Сочту за комплимент. :) Но все же, возвращаясь к subj. Есть ли у приведенной выше схемы какие-либо явные недостатки ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2005, 20:36 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
> 2. Абсолютно все атрибуты хранить в двух вышеуказанных таблицах. Это вообще единственно приемлемый вариант. Потому как: 1. позволяет поддерживать локализацию; 2. позволяет регистрировать особенности (языковые, национальные и пр.) атрибутов; 3. позволяет поддерживать версионность и хронологию изменений; 4. позволяет поддерживать ограничение доступа. > Что же касается сложности выборки по многим атрибутам, то эту проблему прийдется решать так или иначе. А в чем здесь, по-Вашему, сложность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2005, 21:14 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
guest_20040621> 2. Абсолютно все атрибуты хранить в двух вышеуказанных таблицах. Это вообще единственно приемлемый вариант. Потому как: ... Единственно приемлемый... но нерабочий вариант :) Сложность с фильтрацией, отчетностью, агегатными фунциями, проблемы при вставке-изменении данных. И главное скорость... В таком случае я бы смотрел в сторону ООБД ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 12:41 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Estets смотреть можно куда угодно - вот будет ли толк? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 12:52 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
заметки бездельника - реализация "в лоб" Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Если показать все данные на одной таблице: Код: plaintext 1. 2. 3. 4. Q1: фильтрация Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Q2: получение данных Код: plaintext 1. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Q3: агрегирование Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Итого, как мне кажется, все не так чтобы аж совсем просто (ну, а кому щас легко?), но особых-то сложностей нет Не думаю, что в ООБД эдакий изврат проканал бы проще и на порядки быстрее. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 14:00 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
funikovyuri Estets смотреть можно куда угодно - вот будет ли толк? Честно говоря я имел ввиду наличие некоторого гимороя как в использовании ООБД так и в попытках написать решение " на все случаи жизни ". См. примеры любезно предоставленные нам " дураг с инецеативой ". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 15:39 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Что же касается сложности выборки по многим атрибутам, то эту проблему прийдется решать так или иначе. А в чем здесь, по-Вашему, сложность? Все познается в сравнении. Один SELECT или четыре-пять, есть ведь разница ?! :) Но это так, к слову. В общем, выбираю второй вариант. Всем спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 15:42 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich Anton guest_20040621> Что же касается сложности выборки по многим атрибутам, то эту проблему прийдется решать так или иначе. А в чем здесь, по-Вашему, сложность? Все познается в сравнении. Один SELECT или четыре-пять, есть ведь разница ?! :) Но это так, к слову. В общем, выбираю второй вариант. Всем спасибо! На Вашем месте я бы сделал пилотный проект, и посмотрел насколько сложно и насколько быстро возможна обработка данных, я думаю множество вопросов сами по себе отпадут... Но еще раз могу сазать свое мнение три раза джойнить одну таблицу что бы собрать ФИО это несколько странно. А проблемы со вторым вариантом могут быть такие: для предприятия обычно указываются по крайней мере два адреса (юридический и почтовый), а может быть и несколько если предприятие имеет отделения, представительства. Очень желательно что бы адреса соответствовали КЛАДР (особенно для физических лиц) а эту уже почти 10 атрибутов. Лицо может иметь несколько расчетных счетов в банках, опять это не один атрибут а несколько наборов. И т.д.... Если вопрос касается только контрагентов, то это еще пол беды, их редко бывает больше 1000 (если конечно Вы пишете не для СберБанка или МТС), но обычно аналогичный вопрос возникает и по поводу номенклатуры товаров и остальных сущностей БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 16:12 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Раньше только Лисоводы лезли во все дыры, предлагая Fox-решения как панацею. А теперь еще и фанаты ООБД суют свой нос куда попало. Правда, в отличии от Лисоводов они не могут представить ни одного конкретного решения. Я скоро начну любить Лисоводов. Они хотя бы делают работающие базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 17:20 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Я проблему с атрибутами решил так, (убил двух зайцев) Администратор или суперпользователь определяет набор артибутов объекта и перегенерит таблицу. Все это просто и наглядно. Пользователь может и не знать что это таблица. Соотвественно атрибуты являются метаданными для построения пользовательских запросов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 17:20 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Вот похожая ситуация (контрагенты или товары - суть одна) . Но есть одна проблема. Помогите решить. Вообщем говоря: Посмотрите вложение, там картинка с фрагментом из базы. Таблицы: Products - собственно товары ProductGroups - товарные группы с наследованием/иерархией (по ParentID) GroupParams - здесь заводим типы параметров для каждой товарной группы (опять же с наследованием - ParentID) ProductParams - собственно здесь хранятся значения параметров для каждого товара. Далее: Возникла необходимость, чтобы тип параметра (в ProductGroups) имел свои опции, т.е. состоял из набора данных Создаем таблицу ParamOptions И вот теперь не могу решить, как лучше (по науке) привязать эту таблицу к ProductParams , чтобы хранить в ней значение из ParamOptions ? Если просто создать дополнительный столбец в ProductParams и сослаться на него из ParamOptions ? А если решать по другому, то как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 17:44 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Old NickАдминистратор или суперпользователь определяет набор артибутов объекта и перегенерит таблицу. При добавлении нового атрибута к объекту (типу документа) автоматом добавляется поле в таблице (причем нужного типа, в отличии от подхода №2), так работают большинство универсальных систем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 17:47 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
EstetsНа Вашем месте я бы сделал пилотный проект, и посмотрел насколько сложно и насколько быстро возможна обработка данных, я думаю множество вопросов сами по себе отпадут... Но еще раз могу сазать свое мнение три раза джойнить одну таблицу что бы собрать ФИО это несколько странно. Уже. :) 8000 контрагентов, примерно 10 атрибутов. Вот только работают с этой базой всего 3 оператора и самое сложное действие (кроме обычных выборок для интерфейса) - поиск по одному из атрибутов. Пока претензий нет никаких. Что касается расчетных счетов, для этого дела выделил отдельную таблицу. Для того, чтобы хранить номер счета, bank_id, currency_id. Насчет адресов: если возникнет реальная потребность с ними много работать, думаю, можно будет сделать что-то похожее. А до тех пор, пока адрес - это обычная информация для, например, документов, будет так, как сейчас. Old NickАдминистратор или суперпользователь определяет набор артибутов объекта и перегенерит таблицу. Все это просто и наглядно. Пользователь может и не знать что это таблица. Соотвественно атрибуты являются метаданными для построения пользовательских запросов ALTER TABLE ? :) Я об этом думал, но мне показалось слишком экстремальным. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 17:50 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich Anton wrote: > Estets > На Вашем месте я бы сделал пилотный проект, и посмотрел насколько сложно > и насколько быстро возможна обработка данных, я думаю множество вопросов > сами по себе отпадут... Но еще раз могу сазать свое мнение *три* раза > джойнить одну таблицу что бы собрать ФИО это несколько странно. ~500.000 контрагентов, 31 аттрибут, ~50 операторов. даже не жюжжить. Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:05 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich Anton 8000 контрагентов, примерно 10 атрибутов. Вот только работают с этой базой всего 3 оператора и самое сложное действие (кроме обычных выборок для интерфейса) - поиск по одному из атрибутов. Гм, а чем тогда хуже таблица из 10 полей? Такой подход имеет смысл только если написан полностью универсальный интерфейс, когда пользователь может ввести в настройке новый атрибут, напимер "Код ОКПО", и система автоматом покажет эту колонку в списке, позволит сортировать и фильтровать по этому полю, включать это поле в отчетность. Если для добавления атрибута требуется вмешательство администратора в серверную или клиентскую часть, то смысла в этом я не вижу. Тогда Ugnich AntonALTER TABLE ? :) очень даже оправданный подход, позволяющий (если конечно позволяет клиентская часть) автоматом генерить списки на клиенте, с сортировкой и фильтрацией. Упростить или автоматизировать создание форм для ввода. Подлючать отчетные системы типа БизнесОбжектс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:21 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
locky ~500.000 контрагентов, 31 аттрибут, ~50 операторов. даже не жюжжить. А если не секрет, как вы решили вопрос с типми атрибутов? Все в строке или три поля datetime, money, varchar(255)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:26 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Для фанатов экстремальной универсализации - возможен еще и гибридный подход - в течение некоторого времени система работает по варианту 2, накапливая список всех возможных атрибутов - а потом переходит на схему ALTER TABLE, соответсвенно оптимизируя запросы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:31 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich Anton EstetsНа Вашем месте я бы сделал пилотный проект, и посмотрел насколько сложно и насколько быстро возможна обработка данных, я думаю множество вопросов сами по себе отпадут... Но еще раз могу сазать свое мнение три раза джойнить одну таблицу что бы собрать ФИО это несколько странно. Уже. :) 8000 контрагентов, примерно 10 атрибутов. Вот только работают с этой базой всего 3 оператора и самое сложное действие (кроме обычных выборок для интерфейса) - поиск по одному из атрибутов. Пока претензий нет никаких. Что касается расчетных счетов, для этого дела выделил отдельную таблицу. Для того, чтобы хранить номер счета, bank_id, currency_id. Насчет адресов: если возникнет реальная потребность с ними много работать, думаю, можно будет сделать что-то похожее. А до тех пор, пока адрес - это обычная информация для, например, документов, будет так, как сейчас. Old NickАдминистратор или суперпользователь определяет набор артибутов объекта и перегенерит таблицу. Все это просто и наглядно. Пользователь может и не знать что это таблица. Соотвественно атрибуты являются метаданными для построения пользовательских запросов ALTER TABLE ? :) Я об этом думал, но мне показалось слишком экстремальным. :) не ALTER TABLE, а sp_rename 'tablename', '_old_tablename' create tablename ( ... ) insert tablename ( ... ) select ... from _old_tablename ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:32 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
EstetsГм, а чем тогда хуже таблица из 10 полей? Такой подход имеет смысл только если написан полностью универсальный интерфейс, когда пользователь может ввести в настройке новый атрибут, напимер "Код ОКПО", и система автоматом покажет эту колонку в списке, позволит сортировать и фильтровать по этому полю, включать это поле в отчетность. Именно универсальный интерфейс ! :) Я уже говорил, что пишу это не под конкретного заказчика. Захотелось сегодня хранить данные, например, о дне рождения фирмы-контрагента (не важно), юзер добавил поле и везде, где вводится/выводится информация, это поле автоматом показывается. Пользователь (не админ) может добавлять/удалять атрибуты, причем очень легко. Самая вкуснятина - вывод на печать. Есть шаблон документа, в котором есть слова, например, %[День рождения фирмы]%. И система автоматом заменяет в тексте это название атрибута на значение. С варинтом "ALTER TABLE" это было бы сложнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:33 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich AntonСамая вкуснятина - вывод на печать. Есть шаблон документа, в котором есть слова, например, %[День рождения фирмы]%. И система автоматом заменяет в тексте это название атрибута на значение. С варинтом "ALTER TABLE" это было бы сложнее. Если клиент позволяет строить динамический запрос и достучаться до имен полей в БД, то SELECT * FROM ПАРТНЕРЫ WHERE ID=? и подставлять в шаблон значения соответствующих колонок по имени. Примерно так это реализовано у нас на PowerBuilder. Кстати вопрос аналогичный locky , как вы решили вопрос с типми атрибутов? Все в строке или три поля datetime, money, varchar(255)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:46 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Old Nickне ALTER TABLE, а sp_rename 'tablename', '_old_tablename' create tablename ( ... ) insert tablename ( ... ) select ... from _old_tablename А почему такая нелюбовь к ALTER TABLE, если брать именно справочник контрагентов то за последние пару лет он у нас пополнился всего пару раз с введением "КПП" для платежек и "ЕГРН" для отчетов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:54 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Estets wrote: > Кстати вопрос аналогичный *locky*, как вы решили вопрос с типми > атрибутов? Все в строке или три поля datetime, money, varchar(255)? 4 типа: datetime,numeric(19,9),varchar(512),int нечто вроде Код: plaintext 1. 2. 3. 4. идентификатор параметра, Vx - значение параметра. Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:58 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
EstetsЕсли клиент позволяет строить динамический запрос и достучаться до имен полей в БД, то SELECT * FROM ПАРТНЕРЫ WHERE ID=? и подставлять в шаблон значения соответствующих колонок по имени. Примерно так это реализовано у нас на PowerBuilder. Называть имена таблиц/колонок русскими буквами - "я на это пойтить не могу" (С). А иначе - меня юзеры не поймут, потому как им иногда приходиться редактировать шаблоны, в которых эти атрибуты написаны. Нет, все-таки не вижу гибкости в этом решении. EstetsКстати вопрос аналогичный locky , как вы решили вопрос с типми атрибутов? Все в строке или три поля datetime, money, varchar(255)? У меня сейчас два поля: VARCHAR(255), INT. Нужны будут другие типы - добавлю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:59 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
locky Код: plaintext 1. 2. 3. 4. идентификатор параметра, Vx - значение параметра. Так построены только "Контрагенты" или все справочники? Используются ли хранимые процедуры для обработки всего этого? И если не секрет на чем написана клиентская часть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 19:10 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich AntonНазывать имена таблиц/колонок русскими буквами - "я на это пойтить не могу" (С). А иначе - меня юзеры не поймут, потому как им иногда приходиться редактировать шаблоны, в которых эти атрибуты написаны. Нет, все-таки не вижу гибкости в этом решении. Ну всегда возможны алиасы Код: plaintext 1. 2. 3. 4. Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 19:17 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Estets wrote: > Так построены только "Контрагенты" или все справочники? Используются ли > хранимые процедуры для обработки всего этого? И если не секрет на чем > написана клиентская часть? Так построены все справочники, за исключением ведущихся по периодам. Для такого рода информации используется обычная 3НФ Хранимые процедуры используются, да. Без них - никуда :-) Крайне сложно вместить "машину справочников" в client-side скрипты. Клиент написан на Delphi, ранние версии с применением только стандартных компонентов, текущая - применяется Developer Express (очень удобно в некоторых местах, хотя и тормознуто бывает не по детски). >Для фанатов экстремальной универсализации - возможен еще и гибридный >подход - в течение некоторого времени система работает по варианту 2, >накапливая список всех возможных атрибутов - а потом переходит на схему >ALTER TABLE, соответсвенно оптимизируя запросы :) Для фанатов :-) у меня система находится одновременно в нескольких НФ. Те же справочники - вроде бы с одной стороны как-бы 5НФ, с другой стороны - 2НФ. Кстати, применяется кэш-таблица, потому как схема вида объект-аттрибут является очень удобной для разработки, но и правда, с точки зрения быстродейтсвия бывает крайне страшна. Приходится лавировать.... Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 19:23 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
При использовании варианта c DDL операторами в любом виде нужно бы учесть как недостаток невозможность доступа к данным в момент дабавления(удаления, изменения) состава атрибутов сущности. Что бы ни говорили о том, что это де будет делаться раз в пятилетку практика показывает, что такие манипуляции по закону подлости требуются очень срочно и как раз в то время, когда всем нужно работать. А при большом объеме данных могут еще и выполняться недостаточно быстро. То есть простым "Выйти всем на 5 минут" не обойдешься. По моему, вариант с разворачиванием атрибутов по вертикали предпочтительней. По поводу типов, то: 1. Хранить все в текстовом поле + указание типа с последующими преобразованиями. 2. Виделить несколько полей разных типов(кому места не жалко). 3. Завести несколько таблиц для атрибутов разных типов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 20:10 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
SergGol wrote: > 1. Хранить все в текстовом поле + указание типа с последующими > преобразованиями. вах! и морочится потом с этим. А ну как чилдрен умный запихнет значения "Вася" в параметр, который мы искренне считаем датой? и прочие, собссно, вкусности? > 2. Виделить несколько полей разных типов(кому места не жалко). Дык а что, NULL у нас уже место занимает, что его жалеть надоть? как по моему, дык первый вариант с энтой точки зрения - ваще жуть.... > 3. Завести несколько таблиц для атрибутов разных типов. Как показывает практика такое не всегда выгодно, но случаи бывают разные, я вполне могу себе и такое представить. Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 20:27 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
SergGol wrote: > При использовании варианта c DDL операторами в любом виде нужно бы > учесть как недостаток невозможность доступа к данным в момент > дабавления(удаления, изменения) состава атрибутов сущности. Что бы ни > говорили о том, что это де будет делаться раз в пятилетку практика > показывает, что такие манипуляции по закону подлости требуются очень > срочно и как раз в то время, когда всем нужно работать. А при большом > объеме данных могут еще и выполняться недостаточно быстро. То есть > простым "Выйти всем на 5 минут" не обойдешься. По моему, вариант с > разворачиванием атрибутов по вертикали предпочтительней. По поводу Ха! Поле в таблицу добавляется пулей, если, конечно, не задать ему дефолтное значение. По поводу удаления - честно говоря не помню, давно чего-нить удалял. А вот добавление нового аттрибута в конструкцию "Объект-аттрибут"... это да, это есть прелесть. В моей реализации при добавлении нового параметра предполагается добавление оного же во все существующие экземпляры объектов нужного типа (во избежание конструкций left join при выборке параметров, когда у некоторых экземпляров ряд парамметров может отсутствовать) Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 20:31 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
А как все-же насчет вопроса с картинкой в этом топике ? Есть какие-нибудь варианты ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 20:46 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
locky Ха! Поле в таблицу добавляется пулей ... Тем не менее вопрос блокировки таблицы в момент изменения структуры должен быть решен. Понятное дело на таблицу такого рода завязано все. Предположим БД Oracle. В результате изменения сруктуры становятся недействительными куча объектов. Нужна перекомпиляция. Для мссиквела проще, но все равно проблема остается. Получается, что для незначительного в общем действия придеться решать много системных проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 20:50 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
SergGol Тем не менее вопрос блокировки таблицы в момент изменения структуры должен быть решен. Понятное дело на таблицу такого рода завязано все. Предположим БД Oracle. В результате изменения сруктуры становятся недействительными куча объектов. Нужна перекомпиляция. Для мссиквела проще, но все равно проблема остается. Получается, что для незначительного в общем действия придеться решать много системных проблем. С точки зрения ORACLE согласен, если рассматривать MS-Sybase никаких проблем с ALTER TABLE ADD Field не замечал. С удалением полей не связывался, т.е. при удалении атрибута, он удаляется из настройки, но колонка в таблице с данными остается. Что на мой взгляд правильно, что бы потом у пользователей не возникли вопросы "поле на форме нам конечно не нужно, а где данные которые мы туда забили?" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2005, 09:54 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
GordenА как все-же насчет вопроса с картинкой в этом топике ? Есть какие-нибудь варианты ? Я бы добавил в таблицу ProductParams поле Val_OptionID. По логике, ведь, значение из списка параметров - это ещё один "тип данных" ?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2005, 16:50 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1542732]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
147ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
78ms |
get tp. blocked users: |
1ms |
| others: | 239ms |
| total: | 508ms |

| 0 / 0 |
