Имя: Пароль:
1C
1С v8
Регистр сведений. Справочник или регистр.
, , ,
0 МишКа
 
07.11.12
13:55
1. Другое 82% (9)
2. Регистр 18% (2)
3. Справочник 0% (0)
Всего мнений: 11

Только что проскочила тема. В той ветке не удалось поспорить по-существу, поэтому открываю свою.
Итак. Лично я - за справочник. Думаю, если бы разработчики платформы имели представление о составном уникальном ключе, им не пришлось бы плодить лишнюю сущность.
Ваше мнение.
1 Шапокляк
 
07.11.12
13:57
Я за дирижабль

Другое
2 Undefined vs NULL
 
07.11.12
13:57
(0) они имеют представление, именно так и есть в РС
3 Ork
 
07.11.12
13:59
(0) За базАр за "лишнюю сущность" неплохобы ответить.
Всмысле чем это она лишняя?

Вопрос за то имеют / не имеют представление пока опустим.
4 Kreont
 
07.11.12
13:59
(3) ниче не понял
пред.ветку не видел :)

Другое
5 Goggy
 
07.11.12
14:00
отреж себе пальцы на ногах, зачем тебе лишние сущности, да ещё и десяток...

Другое
6 МишКа
 
07.11.12
14:00
(2) Я имел ввиду, что при наличии справочника с возможностью задания составного уникального ключа делает регистры сведений не нужными.
7 Undefined vs NULL
 
07.11.12
14:01
надо было разделить понятие периодического и неперодического регистра нафиг
а так с РН - остатки и обороты
8 Serginio1
 
07.11.12
14:01
Нет пометки удаление, есть измерение ведущее. Индексы для измерений.
Нет родителей, кода, наименования,владельца и прочей лабуды.
Они для разных целей.

Другое
9 Ork
 
07.11.12
14:01
(4) Аналогично. Прочитал только старт этой ветки.
10 МишКа
 
07.11.12
14:01
+(6) наличие ... делает
11 Undefined vs NULL
 
07.11.12
14:01
(2) так кто против то? периодичность эмулировать можно, вся конфигурация на справочниках
12 Aprobator
 
07.11.12
14:02
(6) а нафиг всем справочникам составной ключ?
13 Ork
 
07.11.12
14:03
(6) Такая возможность у вас есть уже сейчас. Называется подчиненный справочник.

Уникальный составной ключ? Так вот жеШ он : УИДВладельца + УИДЗаписи.
14 Undefined vs NULL
 
07.11.12
14:03
(12) почему всем? ))
15 Undefined vs NULL
 
07.11.12
14:03
(13) феерический бред
16 Ork
 
07.11.12
14:04
(15) Сами вы вот это вот.
17 zak555
 
07.11.12
14:05
(0)

справочник - уникальный объект, который теоретические не повторяется ( хотя можно реализовать )
регистры --- записи, которые можно повторить
18 МишКа
 
07.11.12
14:05
(8) По твоей логике должны быть отдельные сущности для справочников с иерархией и справочников без иерархии, справочников подчиненных и не подчиненных. Размер такого дерева конфигурации превысил бы все разумные рамки.
19 МишКа
 
07.11.12
14:06
(17) То есть ты за справочник?
20 cw014
 
07.11.12
14:07
Имхо полезная вещь, но по сравнению с РН оборотным, лучше бы сюда добавили итоги для периодического регистра

Регистр
21 Ork
 
07.11.12
14:08
(18) Стоп... стоп...
Перейдем к ваше логике. Все (основные) объекты базы данных суть таблички. Достаточно одного объекта с миллионом методов? Так было бы лучше?
22 МишКа
 
07.11.12
14:09
(11) Про всю конфигурацию разговор не идет. Есть смысл разделять сущности: справочники, документы, регистры.
Вопрос ставится так. Зачем еще одна сущность - регистр сведений?
23 zak555
 
07.11.12
14:10
(19) т.е. это разные сущности
24 МишКа
 
07.11.12
14:11
(21) Лучше - когда есть сущности необходимые: справочники, документы, регистры. И нет сущностей лишних (регистр сведений).
25 Serginio1
 
07.11.12
14:12
(18) По сути они и есть. В них не прописаны родители владельцы код или наименование. Регистр хорош еще тем, что его легко удалить, в отличие от справочника, т.к. на него нет ссылок.
26 artems
 
07.11.12
14:12
(0) почитай для начала книжки из комплекта поставки, может что то прояснится в голове )

Другое
27 МишКа
 
07.11.12
14:13
(23) Я понимаю, что справочник и объект это разные сущности. Но говорю: то, что называется "регистр сведений" по своей сущности является справочником.
28 zak555
 
07.11.12
14:14
(27) хранятся данные по-разному
29 Serginio1
 
07.11.12
14:14
25 + Вообщето есть у него уникальный _SimpleKey  но вот для чего он, не имею понятия.
30 Serg_1960
 
07.11.12
14:14
(0) Реализуй срез последних на справочнике м.б. тогда ты меня убедишь :)
31 Ork
 
07.11.12
14:15
(24) Ещераз. Базар о "лишних сущностях" требует обоснования.

(22) ЧистоКанкретнаяИМХА. Одна из причин появления РС - проблемы обмена (в РБД, с другими системами ...)

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

Такое себе "вертикальное расщепление" из теории БД.
32 Ork
 
07.11.12
14:18
+(31) Конечно тоже самое можно реализовать на справочниках. Будут называться "Справочники дополнительных реквизитов".
Но вопрос ведь не в названии?
33 Mort
 
07.11.12
14:32
А то что в регистрах может быть больше одного измерения автор слышал?
34 Mort
 
07.11.12
14:33
+(33) Вкупе с тем что у справочников есть уникальная ссылка и с некоторой штукой, которая называется нормализация БД ?
35 vmv
 
07.11.12
14:36
(0) мало какая ерп может похвастаться такое сущностью как регистры, мои знакомые профи-ораклоиды в чистых СУБД на оракле "рожают" эмуляции подобных таблиц самомтоятельно, т.е. ручками и сетуют "у тебя мол разработчики уже прогнулись - бери и пользуйся"

вывод: предлагаю добабавить в голосовалку пункт
4. тс - наркоман
36 vmv
 
07.11.12
14:38
(32) а если к такому справочнику добавить периодность записей(измерение период), то это уже будет мамонт
37 Лефмихалыч
 
07.11.12
14:41
(0) садись - два. регистр от справочника отличают не индексы, а отсутствие и наличие ссылки

Другое
38 SUA
 
07.11.12
14:44
Ибо нефиг

Другое
39 kyrgyz
 
07.11.12
14:46
(0) Автор ветки вы работали с 1с77???
У вас в справочниках были периодические реквизиты?
У вас были тормоза со справочниками в 1с77?
40 kyrgyz
 
07.11.12
14:49
Классная вещь.

Регистр
41 Undefined vs NULL
 
07.11.12
15:17
вот тут шаблон периодических сведений
http://www.sql.ru/forum/actualthread.aspx?tid=620607
42 МишКа
 
07.11.12
15:19
(37) Регистр от справочника отличается предназначением.
В регистре сведений "ссылка" есть, просто она составная.
43 Шурик71
 
07.11.12
15:27
(42) ссылка - это то, на что можно сослаться.
Ты можешь сослаться на запись регистра сведений и поместить ссылку в другой объект?

И вообще.

Ты правда уверен, что для всех случаев лишнее поле ГУИД (которое есть ссылка справочника) ну просто необходимо?

Ты действительно считаешь, что единственный объект, дающий связь "многое ко многим"  , является лишним?
44 Serginio1
 
07.11.12
15:27
(42) Ты понимаешь словосочетание ссылочная целосность?
Нормализация БД?
Это не ссылка, а измерение для поиска. Удаление данной записи не ведет к краху ссылочной целосности. Понятие ведущее для измерения позволяет каскадно удалять записи вместе с удалением ведущего измерения
45 МишКа
 
07.11.12
16:25
(31) Справочник с миллионом реквизитов - плохой справочник.
46 МишКа
 
07.11.12
16:32
Вот и в книге знаний говорится, что регистр сведений по своей сути справочник. Полностью согласен.
47 МихаилМ
 
07.11.12
16:36
измерения рс - поля первичного ключа.

такчто можно считать  рс справочник  с составныс ПК
для которого нужно самостоятельно написать метод
автонумерации.


справочник - прикладная сущность,  которую можно идентифицировать по простому ПК. + второй Уникалный Ключ - номер;

если для всех сущностей требовались бы составные ключи
не было бы типа модификатора IDENTITY increment

Другое
48 МишКа
 
07.11.12
16:43
(47) Почему сразу у всех? У кого-то составной ключ, у кого-то простой. И зачем автоинкремент? Лично меня коды бесят. Зачем их сделали по-умолчанию, да еще так, что без бубна не уберешь? 95 % - код не нужен.
49 Шурик71
 
07.11.12
17:15
Еще раз.

СПРАВОЧНИК.

Обязательные свойства справочника:
- Имеет один ГУИД
- Можно на него ссылаться (размещая его ГУИД)

Дополнительные свойства справочника:
- может иметь код (доп. ключ, уникальность настраиваемая)
- может иметь наименование (доп. неуник. ключ)
- может иметь родителя (доп. неуник. ключ)
- может иметь владельца (доп. неуник. ключ)
- может иметь реквизиты
- может иметь табличные части

РЕГИСТР СВЕДЕНИЙ.

- Не имеет собственного ГУИДа.
- На него нельзя ссылаться.
- Имеет составной первичный уникальный ключ, зависимый от набора измерений.

Дополнительные свойства:
- Может иметь измерения (значения, формирующие составной уникальный ключ)
- Все данные по нему могут быть зависимы от наличия ведущих измерений
- Может устанавливаться регистратором
- Может иметь периодичность (поле период + ВТ для среза)
- Может иметь ресурсы (= реквизиты, значения которых можно получить по составному ключу)
- Может иметь реквизиты (= реквизиты, значения которых нельзя получить по составному ключу)
- Не может иметь табличные части


По-моему, сложно найти менее похожие объекты :)
У справочника с документом больше общего.
Вот бизнес-процесс с документом можно было бы и объединить.. и то различия большие.
50 Mort
 
07.11.12
17:21
Автор просто привык в клюшках эмулировать явно недостающие для функционала регистры справочниками. Почти в каждой 7шной конфе есть куча "виртуальных" справочников, которые никуда не выбираются, а чисто хранят привязки.
51 Шурик71
 
07.11.12
17:25
(49+) кроме того, неясна суть предложения об объединении.

Внести справочник с составным ГУИД-ом? и что с ним делать.
Варианта 2: а) на него можно ссылаться б) на него нельзя ссылаться.

Вариант (б) точно соответствует текущему регистру. Что за справочник, на который нельзя ссылаться? При чем тут будут код и наименование? К чему крепить таб. часть?

Рассмотрим вариант (а). ОК, сделали такой объект. В документе сослались на составной ГУИД (к примеру, из 3х измерений). После чего меняем в записи одно измерение. Составной ключ изменился. Что должно произойти со всеми ссылками?

Короче говоря, вся тема - бред.

Другое
52 МишКа
 
07.11.12
17:42
(51) Хорошо. Поставлю вопрос по-другому.
Есть справочники, документы и регистры.
К какой группе вы отнесете регистры сведений?
53 Undefined vs NULL
 
07.11.12
19:01
составной FK как-то не кошерно, имхо
54 Undefined vs NULL
 
07.11.12
19:02
(48) ну сделай длину 0 ему и все
55 Mort
 
07.11.12
19:08
(52) Есть уши, носы и пальцы. К какой группы вы отнесете ж*пу?
56 vmv
 
07.11.12
20:37
(55) ж*па - это базовый класс для потомков: уши, нос, пальцы, т.к. согласно идеологии опп все растет из ж.. т.е. из базового класса.

двоешник ты
57 МишКа
 
07.11.12
20:37
(48) Сразу видно человека который не часто делает длину кода равной 0.
Не все, ты про бубен забыл.
58 МишКа
 
07.11.12
20:40
(55) Это ты хорошо сказанул.
Только аналогия по-справедливости должна быть такой:
"Есть уши, носы и пальцы. К какой группы вы отнесете ПАЛЬЦЫ ж*пы?"
59 vmv
 
07.11.12
20:42
код справочника - это встроенный реквизит ПОЛЬЗОВАТЕЛЬСКОЙ идентификации записи таблицы БД. Да можно их убрать и в случае пользовтельской идентификации заводить свой собственный, но код - это системный реквизит и по логике запросы к системному более быстрые, чем к своему
60 vmv
 
07.11.12
20:43
(58) ты со своей веткой

нуб и опозорился, теперь отмываться будешь год ибо на тебе уже клеймо - профанчик)
61 МишКа
 
07.11.12
20:44
(60) Ужас-ужас
62 МишКа
 
07.11.12
20:45
(59) Код не нужен в 95% справочников.
63 vmv
 
07.11.12
20:46
(62) ну ты понимаешь, что мнение и статистика дилетантов всегда не объективны, да
64 Undefined vs NULL
 
07.11.12
20:47
(0) давай уже обсудим альтернативную платформу? я серьезно
65 vmv
 
07.11.12
20:48
+(63) потому что они, как правило, не подвержены весомымы фактами и высказаны наобум - лишь бы ляпнуть. Такова сттратегия поведения профанов, смирись)
66 vmv
 
07.11.12
20:50
(64) регистры - это утрированная модель многомерного пространтства, где наполнителем оного является не материя, а информация(данные), что тут обсуждать - теорию многомерных пространств сейчас учат на 1-м курсе вышке, кто не учил, тот проходит по сообщению (65)
67 Undefined vs NULL
 
07.11.12
20:51
(59) чем они быстрее то?
код реально мало где применим, для обменов с внешними системами и там где код имеет осмысленное значение
68 Undefined vs NULL
 
07.11.12
20:52
(66) ну я например могу предложить альтернативную модель регистров сведений, где скорость на чтения и "срез на каждый день запроса" не проблема, правда эта модель имеет меньшую скорость на запись
но где-то это вполне приемлимо
69 МишКа
 
07.11.12
20:53
(64) Я так далеко не думал.
В принципе, меня нынешняя 1С вполне устраивает.
Пусть она несколько аляповата, но базовые принципы - вполне здоровые. Два уровня абстракции. Хороший баланс между физическим и логическим уровнем.
Интересно, что тебе не нравится?
70 Undefined vs NULL
 
07.11.12
20:54
(69) невозможность архитектурного расширения базовых вещей, та же иерархия справочников или (68)
71 vmv
 
07.11.12
20:55
(69) ну вот теперь принялся вылизывать попу 1С - это, между прочим, правильный шаг на пути професонализма и очень полезный навык)
72 МишКа
 
07.11.12
20:58
(71) Лучше дай еще определение регистрам. Они у тебя такие интересные получаются.
73 vmv
 
07.11.12
20:59
(70) альтернативную иерархию для таблицы справочника сейчас можно сваятть В

дсиске
запросе
СКД(только не так как писала та женщина - гуру СКД)

и не надо выть, что тормоза и т.д. на реально больших таблицах работа с иерархией всегда не быстрая и считаеться слабым звеном любой СУБД, хотя некоторые из них все время пытаються отимихировать работу с иерахиями
74 Undefined vs NULL
 
07.11.12
21:02
(73) СКД хороша на отчетах, для логики проведения тоже ее юзать?
кстати, сделай условие В ИЕРАРХИИ в ЛЕВОМ СОЕДИНЕНИИ
75 vmv
 
07.11.12
21:12
(74) ту (73) последнее предложение
76 Undefined vs NULL
 
07.11.12
21:13
(75) отож
77 МишКа
 
07.11.12
21:19
(70) А как сделать так, чтобы в результате не получилась платформа, с которой только ее автор и будет работать?
78 vmv
 
07.11.12
21:21
(77) сделать это очень просто - нужно быть обыкновенным гением, сожалею)
79 МишКа
 
07.11.12
21:22
(78) Сожалеешь о чем?
80 vmv
 
07.11.12
21:27
(79) я уже ответил на этот вопрос в (60)
81 Undefined vs NULL
 
07.11.12
21:30
зануды и критиканы, всё я спать, братцы ))
82 МишКа
 
07.11.12
21:32
(80) Сожалеешь, что эта ветка появилась? И поэтому сюда пишешь? В том числе, юморески про регистры?