|
Применение Local View
|
|||
---|---|---|---|
#18+
Доброго дня всем! Есть теоретически-практический вопрос по применению Local View. Предположим существует обычное бизнес-приложение, в котором есть набор справочников, и основная форма, например, "Счет-фактура" или "ТТН", с большим гридом, в которой данные сводятся в общую таблицу, редактируются, добавляются и удаляются в ней. При этом применяется local view. Согласно прочитанному в книжках, данные нужно нормализовать, т.е. как я это понял, таблицы с данными нужно стремиться создавать таким образом, что бы не допускать дублирования данных. Если следовать этому правилу - то все значения всех данных в такую форму, где источником грида служит local view, подтягиваются из справочников с помощью полей-индексов, или ключей, и потом сохраняются в результирующую таблицу преимущественно эти ключи. Но ведь тогда невозможно редактировать и удалять записи из справочников. А редактировать справочники - нужно. А если делать local view на основе полей результирующей таблицы, тогда да, справочники можно редактировать сколько угодно, предыдущие записи результирующей таблицы сохраняться. Но тогда данные в своем большинстве повторяются, и , вроде, никакой нормализации не получается. Допустимо ли, и правильно (и нужно ли ?) создавать такой view? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2016, 14:18 |
|
Применение Local View
|
|||
---|---|---|---|
#18+
Каша какая-то у тебя. При чем тут вью вообще непонятно. В дочерних таблицах хранишь ID. Например в заголовках С/Ф хранится ID контрагента. Название контрагента в справочнике контрагентов. Удалять их из справочника не надо. Править тоже в разумных пределах, т.е. ООО "Аврора" нельзя переделывать ООО "Аврелий". Если будешь хранить наименование контрагента в заголовках С/Ф, то потом огребешь кучу проблем с поиском всех С/Ф данного контрагента. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2016, 14:27 |
|
Применение Local View
|
|||
---|---|---|---|
#18+
Dima T, view создавал, в том числе, просто что бы создать, ну, поучиться, что ли. Кроме того, прочел, что view полезно, особенно при многопользовательском режиме. Поэтому его и воткнул. Ну, может, view и не причем. Со справочниками такая беда. Существует один справочник с отношением много-ко-многим, одному id_предприятие может соответствовать несколько id_услуга, и, одновременно, одному id_услуга может соответствовать несколько id_предприятие. Решено через три таблицы. А потом еще одна таблица существует, в принципе, тот же справочник, в которой для каждой записи, содержащей id_прибор, id_услуга, id_предприятие устанавливается своя цена, срок и т.п., которые подтягиваются в результирующую таблицу. И вот этот справочник необходимо постоянно редактировать. Согласен, первоначальный вопрос некорректен. Не причем тут view, вопрос, скорее, про организацию таблиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2016, 14:51 |
|
Применение Local View
|
|||
---|---|---|---|
#18+
DmitryKnDima T, view создавал, в том числе, просто что бы создать, ну, поучиться, что ли. Кроме того, прочел, что view полезно, особенно при многопользовательском режиме. Поэтому его и воткнул. Ну, может, view и не причем. Полезно, т.к. это по сути локальный кэш. При открытии закэшировал к себе данные и работаешь с ними. DmitryKnСо справочниками такая беда. Существует один справочник с отношением много-ко-многим, одному id_предприятие может соответствовать несколько id_услуга, и, одновременно, одному id_услуга может соответствовать несколько id_предприятие. Решено через три таблицы. Правильно решено. Только тут проситься id_предприятие_услуга для связующей таблицы. DmitryKnА потом еще одна таблица существует, в принципе, тот же справочник, в которой для каждой записи, содержащей id_прибор, id_услуга, id_предприятие устанавливается своя цена, срок и т.п., которые подтягиваются в результирующую таблицу. И вот этот справочник необходимо постоянно редактировать. Это уже не справочник, а рабочая таблица. Прайс-лист. Тут можно id_услуга, id_предприятие заменить на id_предприятие_услуга, тогда у тебя будет гарантия что не будет использована пара несвязанных id_услуга, id_предприятие. Если это важно. Если неважно, то и так сойдет. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2016, 15:10 |
|
Применение Local View
|
|||
---|---|---|---|
#18+
Dima T, Все именно так, как если бы ты на сам проект посмотрел и та форма Прайс-листом так и называется ) Но из него данные в результирующую таблицу подтягиваются (а там уже состояния - принял, готово, отгружен и т.п.), и поэтому его редактировать, получается, нельзя. А надо. С контрагентами еще ладно, их по id или, на крайний случай по УНП (ИНН, вроде, в РФ) вытащить можно. А прайс - форма динамичная. Вот я и спрашиваю, чего делать? Можно ли просто записи накапливать, частично дублируя инфу и не покрою ли я себя несмываемым позором за это? Или, может, добавить поле, типа "помечен на удаление" и просто скрывать его от пользователя, фактически оставляя в таблице? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2016, 15:41 |
|
Применение Local View
|
|||
---|---|---|---|
#18+
DmitryKnDima T, Все именно так, как если бы ты на сам проект посмотрел и та форма Прайс-листом так и называется ) Но из него данные в результирующую таблицу подтягиваются (а там уже состояния - принял, готово, отгружен и т.п.), и поэтому его редактировать, получается, нельзя. А надо. С контрагентами еще ладно, их по id или, на крайний случай по УНП (ИНН, вроде, в РФ) вытащить можно. А прайс - форма динамичная. Почему нельзя? Правь цены, добавляй, удаляй записи. Что смущает? Таблица Прайс это просто прайс, текущее предложение. Не надо там лишнего хранить. Если надо знать что было раньше, то заведи таблицу история прайса и пиши туда вносимые изменения (дата изменения, ...) Ссылки на прайс (id_прайс) нигде не используй. Добавляешь данные из прайса в "результирующую таблицу" - переноси туда id_прибор, id_услуга, id_предприятие, цена. Дальше прайс уже не нужен, работаешь с этой таблицей. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2016, 15:51 |
|
|
start [/forum/topic.php?fid=41&msg=39357197&tid=1582024]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 145ms |
0 / 0 |