ZloyBrawler
Full Member | Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Цитата: Поэтому говорить о форейнкей и ссылочно целостности на уровне БД и говорить не стоит. | Вы видимо никогда не видели к чему приводит каскадное удаление данных в базе данных написанной тру способом на голом SQL, ну вручную таблички в базе создаются, ключики определяются, связи устанавливаются и все такое в этом же духе. Случайно удаляют спецификацию заказа (а кто запрещал удалять? правильно возможность быть должна!!!), а за ней следом из базы исчезают поступления материалов по этому заказу, производственные заказы действующие и так далее, это жесть... уж лучше лицезреть что-то типа "<Объект не найден> (20:94b81c6f65428d5911e2a8bebc48d793)", при нарушении ссылочной целостности как в 1С, чем пустоту кромешную. Да и "<Объект не найден>" возникает чаще из-за проблем обмена данными между базами данных нежели при обычной работе. По большей части платформа 1С контролирует момент удаления объекта проверяя зависимости и не даст провести удаление объекта, если все зависимые объекты не будут включены в список удаляемых и все зависимые от них и так далее, хотя всегда есть исключения из правил. Для поиска битых ссылок 1С придумала приблуду называемой "Тестирование базы данных", где одной из опций может быть выбран контроль ссылочной целостности базы данных. Цитата: в 1С есть составные типы данных, т.е в одном поле могут храниться ссылки на праймарикей разных таблиц справочников документов и т.д. | Штука вообще восхитительная, видели бы вы попытки сделать, что-то подобное вручную. В итоге получается одна таблица мега список документов всех видов, по праймарикею на нее завязываются сотни таблиц конкретных типов документов, а потом когда тебе нужно узнать, что за документ указан в какой либо ситуации, тебе нужно написать ручками запрос к этой мега таблице, выцепить оттуда тип документа, потом по ключу типа документа, тебе нужно прыгрнуть в таблицу типов документов, цепануть оттуда нужные данные. А это нужно постоянно и получаем горы трудно читаемых запросов. Бывают случаи объединения в одном справочнике справочников вроде бы одного смысла, подразделения, склады, контрагенты, ... а почему бы и нет, есть общие реквизиты, а не общие вынесем в доп таблицы для каждого вида элементов в этом справочнике, а давайте еще версии этих объектов сделаем, и вот в этом справочнике наряду с основными записями есть и версии и основные первоначальные записи. Как же теперь в конкретной ситуации узнать по версии основную? правильно взять и найти и так каждый раз, а еще не ошибиться с типом справочника а еще реквизиты дополнительные из доп таблиц цепануть... говнокод SQL на выходе в 1С каждый вид справочника отдельно и вид документа отдельно, все четко, да на уровне СУБД много таблиц, но зато каждая хранит один вид данных, а не черти знает что. Если нужны версии, храни их в регистрах сведений с привязкой к дате. Проверка типа данных в запросе 1С выглядит примерно так ГДЕ ТИПЗНАЧЕНИЯ(Регистратор) = &ТипРегистратора или ГДЕ ТИПЗНАЧЕНИЯ(Регистратор) = ТИП(Документ.ВидДокумента) или ГДЕ Регистратор ССЫЛКА Документ.ВидДокумента |