|
|
|
Критика структуры базы
|
|||
|---|---|---|---|
|
#18+
У меня есть база на SQL работает по прямыми запросами из 1С. Таблицы - одно направление - одна таблица. Тапа Таблица Клиент- в ней собраны все данные по Клиенту ну и так далее. База работает с 2000 года нареканий по быстродействию нет Число записей в таблицах от 400000 до 50000 Тут пришли спецы (зачем директор их вызвал не знаю) и сказали что база написана неправильно, не надо делать одну таблицу а надо несколько Например таблица адресов, документов ну и така далее. И я вот сижу в прострации и незнаю оставить все как есть или переписать базу. Как определить целесообразность создания одной таблицы, где собраны все данные или 5 раздельных таблиц? Самое главное где почитать про это? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2007, 09:57 |
|
||
|
Критика структуры базы
|
|||
|---|---|---|---|
|
#18+
Целесообразность это не только быстродействие, но и масштабируемость, например наращивание свойств и признаков у сущности. Оно не должно приводить к переделке существующих правил. В случае с одной таблицей такие переделки неизбежны. Простой пример: телефон директора - обычное поле в таблице. Но......неожиданно :) появилась необходимость хранить несколько телефонов: раб., моб., дом., секретарь, приёмная, факс и пр. Прикажете лепить их в одну строку или в новые поля ?????????? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2007, 10:15 |
|
||
|
Критика структуры базы
|
|||
|---|---|---|---|
|
#18+
Если у 1 клиента несколько адресов ? Если адреса меняются и надо хранить их историю ? Если с клиентом связаны несколько документов ? Как у вас это влезет в одну таблицу ? Обычно картотека контрагентов занимает около десятка таблиц или более. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2007, 13:13 |
|
||
|
Критика структуры базы
|
|||
|---|---|---|---|
|
#18+
birraИ я вот сижу в прострации и незнаю оставить все как есть или переписать базу. Как определить целесообразность создания одной таблицы, где собраны все данные или 5 раздельных таблиц? Самое главное где почитать про это? А появились новые функциональные или бизнес-требования для того чтобы иметь 1-к-M адресов, телефонов, документов? Если появились - значит надо рефакторить базу, нет - незачем трогать то что хорошо работает и устраивает бизнес. Тем более, я так предполагаю, что система у вас Data-ориентированная и слои слабо разделены, а при такой ситуации рефакторинг БД - очень сомнительное мероприятие, легче заново все переписать. Только если слои четко выделены и есть хорошо написанный Data Access Layer - тогда есть шанс постепенно и безопасно двигаться в сторону большей нормализации БД. А потом... придут новые спецы и скажут - надо базу рефакторить до 5НФ и на каждое поле по отдельной таблице :) Во всем должен быть разумный смысл, определяемый возникающими требованиями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2007, 15:19 |
|
||
|
Критика структуры базы
|
|||
|---|---|---|---|
|
#18+
Всем спасибо. Переделывать базу не буду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 10:37 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34824829&tid=1544272]: |
0ms |
get settings: |
9ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
176ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 467ms |

| 0 / 0 |
