Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
Добрый день! Разрабатываем базу данных организации которая будет выдавать кредиты займы и т.д. общей структуры договоров нет, она должна быть расширяемая! Вопрос в следующем как, лучше расширять заранее не известную структуру? Есть два варианта, это под новое условия договора создавать таблицу, либо, в одной таблице накапливать поля с новыми условиями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2005, 14:02 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
Однозначно сказать,я думаю, никто не может - но по моему опыту таблицы лучше не плодить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2005, 14:08 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
ИМХО существую 2 пути - либо длинная таблица, либо метаданные не в таблице, а к примеру в XML. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2005, 14:18 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
valik_marchenko Первый вопрос, который я задал бы в таком случае - как используются эти договора. Скажем, если для поиска по трем-четырем основным реквизитам и распечатки - любая нестрогая структура, например набор пар "поле-значение" или XML вполне подойдет. Далее, я спросил бы, не состоит ли договор из некоторого количества [необязательных] частей, логических блоков, типа "реквизиты и контактная информация", "условия кредита", "информация о поручителях" итп. Если состоит, если эти блоки нетривиальны и четко очерчены - завел бы соответствующие сущности, понимая, что расширение может затронуть как добавление полей в эти сущности, так и появление новых сущностей. Далее, я бы накапливал поля, следя за тем, чтобы структура данных оставалась более-менее понятной и управляемой. Тревожным признаком для меня стало бы слишком большое количество бизнес-правил типа "для договоров типа 18 должны быть заполнены поля A, B, C; для договоров типа 45 - те же, что и для типа 18, плюс еще E и F" и так далее. Возможно, в результате такого напопления пришел бы к желанию выделить еще некоторые сущности. Наконец, я бы подумал, не окажется ли уместным ОО-подход. Если в типах договоров есть четкая иерархия, может оказаться удобным просто складывать в одну таблицу объекты-наследники соответствующего базового типа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2005, 15:51 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
> существую 2 пути - либо длинная таблица Плохой путь. > либо метаданные не в таблице, а к примеру в XML. Еще хуже. Целостность как поддерживать собираетесь? "в одной таблице накапливать поля с новыми условиями" + версионность + хранение истории изменений. Остальные варианты сильно сложнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2005, 16:12 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
В одной таблице вряд ли получится. Если структура договора неизвестна, то может он будет включать этапы или транши или еще какие-то множественные части - вот еще таблица. Возможно по траншу потребуется еще таблица для графика платежей. Блоки, о которых говорил softwarer логически обязательно должны быть выделены. Я бы выделил их отдельными сущностями в ER модели, однако они вполне могут лечь в одну физическую таблицу ибо связаны с договором отношением (1 к 1:0). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2005, 16:06 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
valik_marchenkoДобрый день! Разрабатываем базу данных организации которая будет выдавать кредиты займы и т.д. общей структуры договоров нет, она должна быть расширяемая! Вопрос в следующем как, лучше расширять заранее не известную структуру? Есть два варианта, это под новое условия договора создавать таблицу, либо, в одной таблице накапливать поля с новыми условиями. Храните данные вертикально, как ASAP делает. Или почитайте про Oracle FlexFields(R), что в принципе тоже самое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2005, 21:52 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
Relic HunterХраните данные вертикально, как ASAP делает. "Читал пейджер. Много думал" (с) И вспоминал анекдот про то, что русские программисты все как один в совершенстве знают ASAP. Relic HunterИли почитайте про Oracle FlexFields(R), что в принципе тоже самое. Уже упоминали и плюсы, и минусы. Например: "...любая нестрогая структура, например набор пар "поле-значение" или XML вполне подойдет" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2005, 12:47 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
softwarer Relic HunterХраните данные вертикально, как ASAP делает. "Читал пейджер. Много думал" (с) И вспоминал анекдот про то, что русские программисты все как один в совершенстве знают ASAP. Relic HunterИли почитайте про Oracle FlexFields(R), что в принципе тоже самое. Уже упоминали и плюсы, и минусы. Например: "...любая нестрогая структура, например набор пар "поле-значение" или XML вполне подойдет" Да, не все можно реализовать реализовать релационной моделью как того хотелось. Поэтому и выдуманы были тригеры и процедуры. Вполне рабочий вариант. При вертикальном хранении данных отбираются права на прямую модификацию таблиц у пользователей системы. Все данные модифицируются через пакеты/процедуры. By, by. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2005, 20:01 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
Relic HunterПри вертикальном хранении данных отбираются права на прямую модификацию таблиц у пользователей системы. Хм. Меня уже лет семь поражает столь настойчиво пропагандируемое желание "отобрать". Прямо какой-то синдром вахтера :) Можно сделать все. При реализации, адекватной задаче, даже будет работать. Вопрос ровно один - нужно ли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2005, 13:02 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
softwarerХм. Меня уже лет семь поражает столь настойчиво пропагандируемое желание "отобрать". Прямо какой-то синдром вахтера :) Хорошо, что только Вас и каких-то сем лет :) Просто еще не пришли к этому. А те системы, в которых доводилось принимать участие, именно так и сделаны. By ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2005, 17:57 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
valik_marchenkoДобрый день! Разрабатываем базу данных организации которая будет выдавать кредиты займы и т.д. общей структуры договоров нет, она должна быть расширяемая! Вопрос в следующем как, лучше расширять заранее не известную структуру? <...> Могу предложить модель «сущность-атрибут-значение» EAV, обсуждаемую в соответствующей теме этого форума: http://www.sql.ru/forum/actualthread.aspx?tid=220850 Приблизительная ER-модель того, что получится – в прикреплённом файле. Если нужно хранить историю изменений – придётся вводить даты, атрибуты актуальности, придумывать «темпоральные» запросы. Есть ещё пара плохих, по моему мнению, решений: 1) Использовать ООСУБД 2) Модифицировать таблицы и делать интерфейс независимым от количества и названий полей таблиц, но! вести строгую историю модификаций и перед каждой модификацией создавать архив БД, и как только понадобится архивная информация – разворачивать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 12:26 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
В последнем каменте все свойства развернуты в отдельную таблицу, что в принципе ничего не меняет. Есть смешанный способ. В договорах всегда есть присущие всем договорам свойства, они известны уже в начале работы, и куча различающихся, причем часть будут известны в результате эксплуатации. Делается так: 1) Все общие свойства зашивают в одной табличке, по ним быстрее искать, фильтровать, сортировать и пр. 2) Все различные и неизвестные свойства ложат вертикально в отдельную табличку по ключам договоров и ключам свойств, значения либо стринг (в оракле можно variant) либо блоб и все собственно говоря. Когда заказчику понадобилось исчо добавить поле, его ложат в вертикальную табличку. Сохраняют подбором свойств для типа договора из временной таблички. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 13:19 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
softwarer Relic HunterПри вертикальном хранении данных отбираются права на прямую модификацию таблиц у пользователей системы. Хм. Меня уже лет семь поражает столь настойчиво пропагандируемое желание "отобрать". Прямо какой-то синдром вахтера :) . Это скорее всего синдром MSSQL все дано изначально, поэтому лишнее надо отобрать. В DB2 например, надо дать то что попросят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 01:38 |
|
||
|
Cтруктура базы
|
|||
|---|---|---|---|
|
#18+
Валентин КВ последнем каменте все свойства развернуты в отдельную таблицу, что в принципе ничего не меняет. Есть смешанный способ. В договорах всегда есть присущие всем договорам свойства, они известны уже в начале работы, и куча различающихся, причем часть будут известны в результате эксплуатации. Делается так: 1) Все общие свойства зашивают в одной табличке, по ним быстрее искать, фильтровать, сортировать и пр. 2) Все различные и неизвестные свойства ложат вертикально в отдельную табличку по ключам договоров и ключам свойств, значения либо стринг (в оракле можно variant) либо блоб и все собственно говоря. Когда заказчику понадобилось исчо добавить поле, его ложат в вертикальную табличку. Сохраняют подбором свойств для типа договора из временной таблички. Жму руку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 04:43 |
|
||
|
|
start [/forum/topic.php?fid=32&fpage=147&tid=1545598]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
29ms |
get topic data: |
7ms |
get forum data: |
3ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 236ms |
| total: | 337ms |
| 0 / 0 |
