Цитата:
Сообщение от
sukhanchik
2mazzy: Я и не говорил о том, чтобы использовать RecId без TableId. Одно без другого не живет.
Начинается... В минусах ничего про TableID не было
Цитата:
Сообщение от
sukhanchik
А вот как предполагается в таком случае связывать таблицы при необходимости сделать некий лог/журнал/историю в которую сыпятся данные из разных мест?
как обычно: тег + код.
делайте перечисление, каждое значение которого означает таблицу.
Используйте код таблицы.
Четко управляйте своим кодом.
Не допускайте произвольных связей в runtime...
Цитата:
Сообщение от
sukhanchik
Или другой пример. Я хочу "наклепать" журналы ГК (складские журналы и т.д.) из некой своей надстройки. Я хочу сделать связку. Мне очень нравится идея (за вычетом моих минусов) прописать в ЖГК TableId, RecId со ссылкой на мой исходный документ. Независимо от того - какие ключи у меня в таблицах используются.
Мне это очень напоминает споры бейсиководов с паскалеводами насчет типизации.
Или споры Сишников с Сплюс-плюсистами по поводу типизации...
Да, в бэйсике можно использовать переменную под любое значение.
Но зато резко возрастает вероятность ошибки в runtime.
Цитата:
Сообщение от
sukhanchik
Понятно - что одно из решений проблемы - подойти к ней с другой стороны и решить ее другим способом. Но тем не менее - моя модель - она вполне может быть вероятна. Нет?
Да.
Если очень нравится - делайте.
Просто надо понимать, что это заметание проблем под коврик.
Будете трахаться в отладчике
Будете трахаться с отсутствующими перекрестными ссылками (они не учитывают tableID в данных).
Будете трахаться с налаживанием связей в запросах и в отчетах вручную.
Будете трахаться с экспортом/импортом девелоперских проектов (обязательно с сохранением кода объектов)
Будете трахаться с экспортом/импортом данных (каждый обрабатываемый recID увеличивает время импорта).
Зато сэкономите десяток минут во время разработки связи и, возможно, полчаса на нумераторе.