|
|
|
Как лучше провести нормализацию таблицы
|
|||
|---|---|---|---|
|
#18+
В таблице Table1 есть поле, которое отвечает за состояние (1-было, 2-стало, 3-удалено, 4-новое). Хотелось бы от этого уйти, и по возможности хранить ОДНУ запись (если это разумно). Я рассматриваю такие варианты хранения: 1) Оставить все как было, не заморачиваться. 2) Вместо статуса состояния ввести период действия - удобнее для аналитики за период. Интересно, но количество записей останется такое же. 3) Ввести, например, что-то типа битовой маски - 10 - было 2000 - стало 300 - удалено 4000 - новое Тогда две строки из статусов 1 и 2 будет закодировано одной строкой 2000+10=2010 Может есть еще какие-то варианты хранения? Поделитесь знаниями/опытом, буду благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2017, 19:15 |
|
||
|
Как лучше провести нормализацию таблицы
|
|||
|---|---|---|---|
|
#18+
AK-Shah, честно говоря, не очень понятно о чём речь. Ситуацию понял так: допустим есть какой-то заказ. При создании этого заказа в таблицу Table1 записывается какая-то информация о нём. В поле состояния записываем значение 4. Затем в какое-то время информация в заказе была изменена. И при этом в Table1 появляется сразу две записи: все поля со значениями из записи с состоянием 4, но в поле состояние пишем значение 1, и вторая запись с изменёнными значениями полей и в поле состояния пишется значение 2 Ну и далее по прошествии какого-то времени, когда возникла необходимость удаления заказа, то создаём новую запись, в которой все поля имеют значения из строки со значением состояния 2, но в поле состояния записывается значение 3 То есть получается что-то типа такого: Field1 Field2 Field3 Status1 test 35 41 test 35 1222 48 2222 48 3 Я правильно понял ситуацию? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2017, 06:51 |
|
||
|
Как лучше провести нормализацию таблицы
|
|||
|---|---|---|---|
|
#18+
AK-ShahВ таблице Table1 есть поле, которое отвечает за состояние (1-было, 2-стало, 3-удалено, 4-новое). 3) Ввести, например, что-то типа битовой маски - 10 - было 2000 - стало 300 - удалено 4000 - новое Тогда две строки из статусов 1 и 2 будет закодировано одной строкой 2000+10=2010 Вот тут совсем запутался, а зачем? Т.е. конкатенация Вам не нравиться? Тогда две строки из статусов 1 и 2 будет закодировано одной строкой 1||2=12 AK-ShahХотелось бы от этого уйти, и по возможности хранить ОДНУ запись (если это разумно). Нет препятствий патриотам, делай отдельную таблицу и все записи с "архивными" состояниями (которые я надеюсь все таки нужны) - туда. Только я не очень понял по состояниям ... какое из них считать active, 4-новое или 2- стало .... ну т.е. как по мне странное разбиение. AK-Shah2) Вместо статуса состояния ввести период действия - удобнее для аналитики за период. Интересно, но количество записей останется такое же. Тут тоже вопрос зачем период, в жизни хватит Active_date и Parent_id тогда одним запросом можно построить всю историю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2017, 10:04 |
|
||
|
Как лучше провести нормализацию таблицы
|
|||
|---|---|---|---|
|
#18+
AK-Shah, Посмотрите возможности Flashback Data Archive. Например здесь: https://docs.oracle.com/database/121/ADFNS/adfns_flashback.htm#ADFNS1008 В таблице хранится текущее состояние строки, в архиве хранятся все предыдущие состояния. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2017, 14:58 |
|
||
|
Как лучше провести нормализацию таблицы
|
|||
|---|---|---|---|
|
#18+
MaximaXXL, авторТут тоже вопрос зачем период, в жизни хватит Active_date и Parent_id тогда одним запросом можно построить всю историю А можно пример? Иерархический справочник еще представляю, а это что-то нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2017, 18:54 |
|
||
|
Как лучше провести нормализацию таблицы
|
|||
|---|---|---|---|
|
#18+
авторНет препятствий патриотам, делай отдельную таблицу и все записи с "архивными" состояниями (которые я надеюсь все таки нужны) - туда. Только я не очень понял по состояниям ... какое из них считать active, 4-новое или 2- стало .... ну т.е. как по мне странное разбиение. 1) Статус 4-новое и 2-стало - абсолютно одинаковые по статусу, лишь указывают, КАК именно были получены эти состояния. Увы, как раз не я придумал, как раз я и хочу уйти от этого, интуитивно понимаю, что это это неправильный способ хранения различных состояний. 2) А чем будет существенно отличаться хранение статусов в архиве и в одной таблице? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2017, 19:03 |
|
||
|
Как лучше провести нормализацию таблицы
|
|||
|---|---|---|---|
|
#18+
что-то мне подсказывает, что это таблица аудита, заполняемая триггером. при добавлении записи в основную таблицу, триггер записывает в таблицу аудита строчку 4-новое. при изменении появляются 2 строки : 1-было, 2-стало. при окончательном удалении, соответственно, 3-удалено. напишите смысл таблицы. это аудит или история спецификации заказа или вы таким способом решаете разграничение доступа? в любом случае, надо знать зачем нужна таблица, чтоб посоветовать вам структуру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2017, 20:52 |
|
||
|
Как лучше провести нормализацию таблицы
|
|||
|---|---|---|---|
|
#18+
georgy_g, Это история спецификации заказа. Скажем, у нас был стол (состояние 2). К нему прикрутили направляющие для ящиков и сделали ящики. Состояние стола изменилось (стало 4). Разумеется, храним не только сами состояния, но и описания, каков состав этого состояния. P.S. Интересно про Oracle Flashback Technology, но как бы это выглядело в моем случае - пока не понятно. Буду читать до просветления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2017, 04:33 |
|
||
|
Как лучше провести нормализацию таблицы
|
|||
|---|---|---|---|
|
#18+
AK-Shah, я б остановился на п2 (добавить даты с по) в зависимости от нужд, возможно б создал индекс status,start_date ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2017, 09:18 |
|
||
|
Как лучше провести нормализацию таблицы
|
|||
|---|---|---|---|
|
#18+
AK-ShahMaximaXXL, авторТут тоже вопрос зачем период, в жизни хватит Active_date и Parent_id тогда одним запросом можно построить всю историю А можно пример? Иерархический справочник еще представляю, а это что-то нет. Что-то вроде такого Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Т.о. можно оставить статус в 3 положениях (Активна, История, Закрыта) - так нагляднее А можно строить на Parent_id (null - Активна, id - История и например -1 для закрытых) - не наглядно, надо коментмровать. Active_date - дата когда изменения вступили в силу. И вы всегда можете видеть как долго действовали данные видя дату между 2 строк. По Parent_id можно проследить изменения от и до. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2017, 16:45 |
|
||
|
Как лучше провести нормализацию таблицы
|
|||
|---|---|---|---|
|
#18+
имеем таблицы Заказ и Спецификация_заказа. 1 Вариант В спецификации заказа убрать поле состояния, добавить два поля: дата с , дата по. при селекте актуальной версии заказа брать по датам. 2 Вариант Вести "Редакцию спецификации заказа". Это отдельная таблица с датой. При очередном изменении спецификации создаётся запись в таблице редакции. Строки спецификации цепляются именно к таблице редакции. То есть при начале либо окончании редактирования, сохраняется новая редакция. Устройство строк спецификации для редакции решать вам. Я бы дублировал строки из предыдущей редакции и менял их для текущей. Есть ещё много способов ведения истории, всё зависит от бизнес-задачи. Если клиент скажет "мы подумали и решили оставить первоначальную версию", то вы легко откроете самую первую редакцию. AK-ShahЭто история спецификации заказа. Скажем, у нас был стол (состояние 2). К нему прикрутили направляющие для ящиков и сделали ящики. Состояние стола изменилось (стало 4). Разумеется, храним не только сами состояния, но и описания, каков состав этого состояния. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2017, 17:00 |
|
||
|
Как лучше провести нормализацию таблицы
|
|||
|---|---|---|---|
|
#18+
SQL*PlusПосмотрите возможности Flashback Data Archive Не стоит. Лучше посмотреть на http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/r1/ilm/temporal/temporal.html потом осознать, что поддержка этого дела оракелем пока что находится на уровне синтаксического сахара и сделать обычную версионку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2017, 17:10 |
|
||
|
|

start [/forum/topic.php?fid=52&tid=1885725]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
164ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
29ms |
get tp. blocked users: |
1ms |
| others: | 226ms |
| total: | 450ms |

| 0 / 0 |
