Вход | Регистрация


1С:Предприятие ::

Метки: 

Какую модель базы данных выбрать

Я
   alexshape
 
05.07.18 - 11:01
Привет всем, во внешней системе, реализовано решение, которое необходимо в какой то мере повторить. Данные там хранятся не как в 1с, вид 2 на скрине, а как на виде 1. https://ibb.co/ifOSUy  
для своего пользователя  они выводят данные как в 1с,

вопрос, стоит ли организовывать такую структуру в 1с? какие риски при такой организации данных могут возникнуть?
 
  Рекламное место пустует
   alexshape
 
1 - 05.07.18 - 11:01
"для своего пользователя  они выводят данные как в 1с, "  имею ввиду в пользовательском режиме, а структура  хранения как доп реквизиты в 1с
   arsik
 
2 - 05.07.18 - 11:03
(0) А если свойства добавятся?
   alexshape
 
3 - 05.07.18 - 11:04
(2) Возможно и такое, добавлять реквизит наверное придется
   Aleksandr N
 
4 - 05.07.18 - 11:06
(0) Сегодня вроде не пятница же.
   Малыш Джон
 
5 - 05.07.18 - 11:06
(0) Дык РС "Значения свойств объекта", не?
   alexshape
 
6 - 05.07.18 - 11:18
(5) как я знаю, вопрос в том стоит ли ?
   Малыш Джон
 
7 - 05.07.18 - 11:20
(6) стОит или не стОит - решать тебе, я к тому, что такой объект в 1С уже сто лет как есть и про преимущества и недостатки можно легко найти информацию
   Остап Сулейманович
 
8 - 05.07.18 - 11:21
(6) Теория баз данных настаивает на варианте 1. Хотя в определенных случаях допускает денормализацию до варианта 2.
   Остап Сулейманович
 
9 - 05.07.18 - 11:22
   alexshape
 
10 - 05.07.18 - 11:46
(8) "Теория", меня больше интересует реалии 1с
 
  Рекламное место пустует
   Джинн
 
11 - 05.07.18 - 11:48
(10) Вы о чем это пишете сейчас? О каких таких "реалиях"?
   alexshape
 
12 - 05.07.18 - 11:52
(11) Работа с такой структурой данных (варианте 1), когда все типовые сделаны с вариантом 2 (исключая доп реквизиты). Построение запросов и т.д.
   Остап Сулейманович
 
13 - 05.07.18 - 11:58
(12) "когда все типовые сделаны с вариантом 2" Вы не понимаете о чем пишите.
1. Контактная информация.
2. Договора контрагентов.
3. Данный физ лиц.
...
и прочая и прочая и прочая... Все нормализовано. Хотя бы до первой формы.
   alexshape
 
14 - 05.07.18 - 12:03
(13) Хорошо, по Вашему таблица варианта 1, это какая нормальная форма?, и есть ли объект в типовых конфигурациях с такой структурой данных (доп. реквизиты не в счет)
   Остап Сулейманович
 
15 - 05.07.18 - 12:05
(14) С какой такой структурой? Я же вам написал - "договора контрагентов". Для примера.
   Остап Сулейманович
 
16 - 05.07.18 - 12:08
+ (15) Я надеюсь на таком примере будет понятна разница между
Контрагент1, Договор1, Договор2, ... ДоговорN
и
Контрагент1, Договор1
Контрагент1, Договор2
Контрагент1, Договор3
...
Контрагент1, ДоговорN

а вообще почитай уже https://habr.com/post/64524/ Там в стиле "для больших и маленьких. на селе и в городе". Ну в смысле все просто расписано. Зачем и когда.
   alexshape
 
17 - 05.07.18 - 12:09
(15) с структурой как в варианте 1
   Вафель
 
18 - 05.07.18 - 12:10
Если не типовая конфа. то добавление реквизитов предопчтительнее, чем свойств
   Джинн
 
19 - 05.07.18 - 12:10
(12) Все типовые сделаны по разным "вариантам". И по первому, и по второму. Причем я не врубаюсь вообще что вы хотите. Вопрос в чем? Чтобы Вам прочитали краткую лекцию по теории нормализации баз данных?
   Остап Сулейманович
 
20 - 05.07.18 - 12:13
+ (17) Ну тогда - еще раз. Третий. Но это уже последний.

Договора контрагентов вынесены в отдельную таблицу. Средствами платформы установлена связь по владельцу. И таблица договоров выглядит ровно по варианту 1. Есть ведущее поле "Владелец" и кортеж реквизитов конкретного договора. Причем записей с одинаковым значением поля "Владелец" может быть несколько.

В таблице контрагентов нет полей "Договор1", "Договор2"...
   Вафель
 
21 - 05.07.18 - 12:14
(20) ты описываешь подчиненные таблицы, а это реквизиты - совсем другое
   alexshape
 
22 - 05.07.18 - 12:15
(21) Слава богу
   Вафель
 
23 - 05.07.18 - 12:16
Свойства они нужны, чтоб в конфигуратор не лезть.
А так в них никакой пользы нет
   Малыш Джон
 
24 - 05.07.18 - 12:16
(21) а таблицы реквизитов отличаются от таблиц подчиненных объекта?
   Малыш Джон
 
25 - 05.07.18 - 12:17
+(24) *подчиненных объектов
   alexshape
 
26 - 05.07.18 - 12:19
(24) (25) подчиненные объекты однотипные, а реквизиты они нет
   Остап Сулейманович
 
27 - 05.07.18 - 12:19
(21) "подчиненные таблицы" - понятие чисто 1С. Я пытаюсь описать принцип.
По своей сути - таблицы регистров сведений тоже "подчиненные таблицы". Точно так же как и табличные части и подчиненные справочники.
Вспомните историю с данными "контактная информация". В одно время это был подчиненный справочник. Потом регистр сведений. Потом табличная часть.
Вся разница - это наличие платформенных методов для работы с ними.
   Джинн
 
28 - 05.07.18 - 12:20
(26) Далеко не факт :)
   Вафель
 
29 - 05.07.18 - 12:21
(27)Отношение "один к многим" - если тебе не нравится термин подчиенные таблицы.
А тут речь совсем про другое
   Вафель
 
30 - 05.07.18 - 12:23
(27) КИ хранится в таблице потомучто не известен заранее споск всех видов КИ
   Малыш Джон
 
31 - 05.07.18 - 12:24
(26) ты не поверишь, но подчиненные объект - они тоже могут быть разных типов.
да и не в этом дело, что разве разные типы хранятся в таблицах по разному?
   Остап Сулейманович
 
32 - 05.07.18 - 12:24
(30) Никто не мешает их хранить в РС или подчиненном справочнике.
   alexshape
 
33 - 05.07.18 - 12:25
(16) в Вашем примере:

Ссылка      | ДоговорКонтрагента
------------|-----------
Контрагент1,| Договор1
Контрагент1,| Договор2

Это как раз таки вариант 2.



если как в варианте 1 то было бы 

Ссылка      | Свойство           | значение
------------|--------------------|----------
Контрагент1,| ДоговорКонтрагента | Договор1
Контрагент1,| ДоговорКонтрагента | Договор2

Вот скажите мне теперь , Вариант 1 Это разве нормализованная таблица?
 
 
   Малыш Джон
 
34 - 05.07.18 - 12:25
(30) насколько я понимаю, в исходной задаче (0) - тоже
   Малыш Джон
 
35 - 05.07.18 - 12:26
(33) а чем у тебя первый и второй вариант отличаются? Полем "Свойство"?
   Остап Сулейманович
 
36 - 05.07.18 - 12:27
+ (32) И одна из причин следовать теории баз данных то - что состав реквизитов у разный ведущих объектов неизвестен. См (3).
Кроме того у разных "ведущих" может оказаться разное количество реквизитов. Придется заготовку делать с запасом.
   Вафель
 
37 - 05.07.18 - 12:27
(32) ТЧ, Поддчиненный справочник или РС - это технологически одно и тоже
   Малыш Джон
 
38 - 05.07.18 - 12:27
+(35) первый и второй вариант - не из (0), а из (33)
   Вафель
 
39 - 05.07.18 - 12:30
Но если у разных объектов - разное количество реквизитов (типо характеристик: у одних длина у других вес), то лучше через свойства
   alexshape
 
40 - 05.07.18 - 12:34
(38) в первом варианте можно добавлять новую строку(бзе добавления полей):

Контрагент1  | ТипКонтрагента  |   Конкурент

а чтобы это сделать во втором варианте нужно добавить новое поле "ТипКонтрагента"
   alexshape
 
41 - 05.07.18 - 12:38
(36) вы говорили что в типовых есть примеры как в 1 варианте, я так и не нашел тот пример что (16), я уже в (33) написал
   alexshape
 
42 - 05.07.18 - 12:39
(41) не так написал:

вы говорили что в типовых есть примеры как в 1 варианте, я так и не нашел такой пример.

А тот что в (16), я уже в (33) написал
   Малыш Джон
 
43 - 05.07.18 - 12:44
(40) так я про что и говорю:
один раз добавить "свойство" - и все, и это превращается в вариант со свойствами. Разовое изменение - не делает эти схемы принципально разными.

вот когда ты используешь схему Контрагент1|Договор1|Договор2 , тогда КАЖДЫЙ раз когда тебе понадобится новое свойство, ты будешь добавлять новое поле.

а в (33) - разница только в одном-единственном РАЗОВОМ изменении
   pavig
 
44 - 05.07.18 - 12:44
(0)
ТС, тут всё просто:
если все объекты в данный момент времени обладают одинаковым набором свойств, то вообще не парься - делай таблицу Вид 2.
Если же у тебя объекты имеют разный набор свойств (например, хранишь контактную информацию или хранишь договоры контрагента), то есть количество этих свойств сильно различается или предполагается их большое количество, то делай Вид 1.
   alexshape
 
45 - 05.07.18 - 12:49
Просто автор поста (36) меня запутал, и я хочу понять кто из нас ошибается, потому что он говорит что в типовых конфигурациях организованна структура Вариант 1, я говорю что нет. просто сомнений не хочется у себя оставлять
   pavig
 
46 - 05.07.18 - 12:54
(45)
Во всех типовых повсеместно используется и Вид 1, и Вид 2
   alexshape
 
47 - 05.07.18 - 12:57
(46) А ты можешь мне привести пример Вид 1?
   pavig
 
48 - 05.07.18 - 13:00
(47)
В этой ветке уже приводили. Самое явное - Контактная информация, Значения доп сведений объектов и т.п.
   Зуекщмшср
 
49 - 05.07.18 - 13:15
(0) Не понимаю, к чему сюда теорию БД приплели, нормализацию, и т.д. У случая 1 плюс - простота в обслуживании и масштабируемость, у случая 2 - быстродействие. Все, выбирай, что тебе важнее.
 
  Рекламное место пустует
   Малыш Джон
 
50 - 05.07.18 - 13:15
(49) взял и всю систему поломал)
   ptiz
 
51 - 05.07.18 - 13:17
(0) Свойства нужны, если:
1) справочник номенклатуры сильно "разношерстный", а у разных групп номенклатуры сильно разные реквизиты.
2) высоконагруженная база в режиме 24/7, а реквизиты часто добавляются.

Иначе - конечно реквизиты удобнее.
   YaFedor
 
52 - 05.07.18 - 13:23
Вариант 1 плох только одним:

Во встроенном языке невозможно нормально написать алгоритмы, для которых будут нужны значения конкретных свойств.

Именно поэтому в типовых в объектах существуют реквизиты.
   alexshape
 
53 - 05.07.18 - 13:44
(49) Меня это и поставило в тупик, я все капаю про нормализацию базы, и не нахожу нужного.
   alexshape
 
54 - 05.07.18 - 13:46
(53) Я просто не программировал на других языках, неужели в не в 1с таблицы выглядят как то по-другому?



Список тем форума
  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует