Пишу для себя кое-что. Хочу сделать работу с базой данных, ориентируясь на то, как это сделано в 1С (7.7, поскольку с 8-кой не знаком).
С базами данных на ты не знаком - придется доучиваться.

Хотел воспользоваться здешним кладезем знаний в области 1С и БД.

Есть много вопросов, но хотел пока-что начать с этого: объекты неопределенного вида.
Возьмем, к примеру, справочники неопределенного вида.

1. Удобно? Часто ли используете реквизиты типа "Справочник" (т.е. справочник неопр. вида)?

2. Полезно? Нет ли каких противопоказаний (пусть и субъективных) к их использованию? Например, эстетических. Или это порочная практика, могущая запутать работу? Или еще что?

3. Наилучшая реализация? В 7.7 ДБФ ID (далее ИД) хранится как строка. Если справочник неопределенного вида, в ИД включается код вида справочника.
Если я буду реализовывать справочники неопр. вида, не лучше ли ИД иметь числовой (быстрота и универсальность для разл. баз данных), а код вида справочника хранить в дополнительном поле, и отбор делать по этим двум ключам?

Извините за возможно неправильную терминологию и глупые вопросы.

ev-kov писал(а) 25. Декабря 2010 :: 17:03:

Python + PyQt4
http://www.1cpp.ru/forum/YaBB.pl?num=1292697586
спасибо за ответ

steban писал(а) 26. Декабря 2010 :: 12:57:

Может и универсально, но, имхо:
-слишком сложно для меня
-слишком много джойнов - нечитабельно при ручном разборе таблиц

в любом случае познавательно - спасибо за ссылку

blindvic писал(а) 26. Декабря 2010 :: 14:09:

Любопытно, в чем-то пересекается с моими размышлениями. Из существенных отличий моей модели (пока только в качестве идеи, до реализации еще далеко)
1) наличие у каждого из значений отдельных дат (Дата начала знания - когда мы узнали о данном свойстве объекта, Дата окончания знания - когда значение было скорркетировано - эти даты нужны для целостной и непротиворечивой работы с "исправлениями задним числом", Дата начала действия и Дата окончания действия)
2) В качестве связей я планирую использовать концепцию "Документ", т.е. все связи образуются строго посредством документов. Никаких иных "неявных" связей быть не должно.
3) В связи с п.2 надо продумать и структуру хранилища, чтобы хранить нужные поля документов, с режимами отображения, автообновления и прочими "плюшками". Кроме того необходимо продумать еще и концепцию "принять документ к учету", т.е. документ может просто вводиться и, при этом, не создавать какие-либо свойства у объектов, далее документ может быть принят к одному виду учета (и создать объекты и свойства на этом уровне), далее идет принятие по второму виду учета (и соответствующие объекты и свойства) и т.д. (например приходная накладная - принимается изначально только в управленческом учете и создает товарные остатки, и лишь после принятия по бух. учету фиксирует суммы на бухгалтерских счетах)
4) Кроме, собственно, хранилища данных, необходимо хранить также и логику, для чего планирую использовать концепцию "Регистра правил"
Так что моя модель существенно "тяжелее" в проектировании

(0) недостаток, и большой - если будут нужны доп. реквизиты  - придётся присоединять все виды справочников (или только те, которые "могут" попасть в этот реквизит неопределенного вида)...
Т.е  будет дополнительно куча левых джоинов.

Dmitry The Wing писал(а) 27. Декабря 2010 :: 08:28:

А если в 90% комментария нет?

В справочнике Комментарии хранится не только текст, но и куча доп. инфы (дата создания, изменения, автор...) + форма, котролирующая поведение - проверки и т.п.

blindvic писал(а) 27. Декабря 2010 :: 10:07:


Если нужно потом доставать реквизиты с этого справочника, то да..
Особенно, если эта ссылка в измерении торчит (КредДок в Покупателях, к примеру).