Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
Всем привет! Такой вопрос об архитектуре бд: Есть таблица некоторых объектов ObjectTable. Объекту соответсвует некоторые разносмысловые группы параметров, например M={M1,M2,M3,M4}, N={N1,N2,N3}, P={P1,P2,P3,P4,P5}. Вариант первый - всё свести в одну таблицу c колонками: ObjectTable: ObjectID (PK),ObjectName,M1,M2,M3,M4,N1,N2,N3,P1,P2,P3,P4,P5 Вариант второй - разнести параметры в разные таблицы ObjectTable: ObjectID (PK),ObjectName M_ParamTable: ObjectID (FK на ObjectTable.ObjectID)+(UniqueKey),M1,M2,M3,M4 N_ParamTable: ObjectID (FK на ObjectTable.ObjectID)+(UniqueKey),N1,N2,N3 P_ParamTable: ObjectID (FK на ObjectTable.ObjectID)+(UniqueKey),P1,P2,P3,P4,P5 Мне кажется, что надо всё сливать в одну таблицу, но увидел некую базу, где часть параметров вынесена в отдельную таблицу и вот задумался. Как нужно правильно делать? Если вопрос очень ламерский - то напишите, пожалуйста, литературу, где этот вопрос объясняется. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 12:17 |
|
||
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 12:29 |
|
||
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
Все в одну таблицу, но не по вашему варианту :) Вот так: Код: plaintext 1. 2. 3. 4. 5. 6. Тогда у вас не будет проблем с добавлением новых параметров. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 12:33 |
|
||
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
andrey - этот топик я прочёл, прежде чем запостить этот вопрос - у меня другой вопрос. tygra - в моём случае твой вариант не подходит совсем, так как у меня список параметров постоянный. для каждого объекта все параметры определены однозначно - просто могут отсутствовать данные для этих полей примерно в половине случаев. вобщем, я подумал и решил , что ту базу что я видел - это чей-то глюк и надо сливать всё в одну таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 13:07 |
|
||
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
Абстрактные вопросы: Интересно, почему все считают, что их постановка задачи самая последняя и наиболее верная? Почему никто и никогда не думает о возможных рассширениях, добавлениях и изменениях? Почему многие считают опыт других просто "глюком" ... и зачем тогда просят советов здесь? Andrey ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 14:10 |
|
||
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
to tygra and all кто знает Код: plaintext 1. 2. что-т ни как определиться не могу, как при такой организации поступить с параметрами с дес. точкой. типа decimal(8.2) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 07:55 |
|
||
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
Sergey_SKValue какой тип предполагается - sql_variant? что-т ни как определиться не могу, как при такой организации поступить с параметрами с дес. точкой. типа decimal(8.2) ? Как один из вариантов использовать для поля Value тип VARCHAR. Мы как раз его использовали для хранения данных разного типа ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 13:49 |
|
||
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
Andrey ...использовать для поля Value тип VARCHAR. Мы как раз его использовали для хранения данных разного типа ... И что, при каждом обращение делаете приведение типов? Для хранения данных разного типа я склоняюсь использовать разные таблицы, вот только с decimal не знаю как поступать? Использовать float, до этого старался ни кагда его не использовать из за частого вываливанея у клиентов в експоненциальный вид, да и ещё пишут что при вычислениях "точность вычислений оставляет желать лучшего" что в свое время я перевёл как "за результат мы не отвечаем" и пользовал всегда decimal. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 14:37 |
|
||
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
Sergey_SK И что, при каждом обращение делаете приведение типов? Делаем ... при необходимости. В зависимости от размера это не так уж дорого стоит. И это самый удобный способ хранения однотипного рода данных. Кстати не только упомянутые вами, но том числе и дат... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 16:01 |
|
||
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
to Andrey У вас хранимые процедуры и функии это 99% динамический sql ? Если, например, для дат отвести свою таблицу то и приведение типов делать будет незачем, количество динамического sql вероятно уменьшится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2004, 07:06 |
|
||
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
Я такой вариант использую: ParamType_ID, Object_ID, Prm_Str, Prm_Date, Prm_Int, Prm_Float, ... Но, в таблице объектов, Object_ID, Prm1, Prm2, Prm3. Несколько наиболее часто используемых параметров: Tag, Memo, Name, Мне очень удобно и проблем нет вообще, а там уже Вам решать. Универсально, но без фанатизма. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2004, 11:49 |
|
||
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
Sergey_SKto Andrey У вас хранимые процедуры и функии это 99% динамический sql ? Если, например, для дат отвести свою таблицу то и приведение типов делать будет незачем, количество динамического sql вероятно уменьшится? Я извиняюсь, но никаким динамическим sql и не пахнет. Зачем он!? Если надо производить вычисления по этим полям, то просто cast'ом пользуемся и все. Но как правило подобные структуры используются для хранения различного вида настроек и особых преобразований не требуют вообще. А как Вы представляете запрос где нужно вывести, к примеру, все данные из таблицы и где сами значения хранятся в дополнительных таблицах, соответствующих своему типу? Вы думаете что это будет гораздо оптимальнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2004, 12:57 |
|
||
|
архитектура БД - параметры в одну таблицу или в разные?
|
|||
|---|---|---|---|
|
#18+
Andrey Но как правило подобные структуры используются для хранения различного вида настроек и особых преобразований не требуют вообще. Различного рода настроек это не совсем то, вот организовать таким образом хранение параметров обектов. Andrey ...использовать для поля Value тип VARCHAR. В вашем случае конечно же получить список всех параметров и их значений проще. А вот как проводит вычисления, бизнеслогику, там отчёты всяки разны строить... Если хранить разные типы параметров в разных таблицах то тут всё в порядке и контроль типов к тому же будет. Andrey А как Вы представляете запрос где нужно вывести, к примеру, все данные из таблицы и где сами значения хранятся в дополнительных таблицах, соответствующих своему типу? Вы думаете что это будет гораздо оптимальнее? Вот в этом случае и делать приведение типов, всех к типу VARCHAR, и обединять union. Конечно если нужно все и сразу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2004, 14:59 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=163&tid=1546261]: |
0ms |
get settings: |
11ms |
get forum list: |
22ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
10ms |
get forum data: |
4ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 273ms |
| total: | 430ms |

| 0 / 0 |
