Здравствуйте!
В базе данных есть две таблицы: это UT_Companies(Компании) и UT_Accounts(Аккаунты).
Две таблицы находятся в отношении один ко многим, то есть у одной компании может быть сколько угодно много аккаунтов. У таблицы аккаунтов есть поле "номер аккаунта" и дата его создания.
У каждой компании из всех аккаунтов есть основной аккаунт, который выдавался сразу же при заключении договора с компанией. И поэтому в системе отчетности в нашей компании всех наших контрагентов удобно называть не по наименованиям (поскольку часто наименования очень похожи друг на друга),а по номерам главного аккаунта, тем более что этот номер аккаунта уникальный в пределах не одной компании, а всего справочника. В связи с этим в запросах постоянно нужно получать номер главного аккаунта (или можно даже так сказать что номер компании) и естественно этот запрос повсеместно будет проще строить, если этот номер будет являться полем таблицы компаний (UT_Companies), но с архитектурной точки зрения будет правильно в таблице компаний иметь ссылку на главный аккаунт. При этом естественно запросы усложнятся. Также при этом возникнет такая коллизия: до создания любого аккаунта, необходимо создать компанию, но компания в таком случае должна содержать ссылку на главный аккаунт, которого еще нет.
Посоветуйте, что можно сделать в этой ситуации или по Вашему мнению может лучше просто дублировать поле номера главного аккаунта в таблице компаний?

Nafа если триггер при вставки новой компании по-умолчанию создавать аккаунт, делать его главным - заполнять ссылку в таблице компаний. Потом можно редактировать этот аккаунт отдать пользователю.
С уважением, Naf
Это принципиально можно будет сделать только в триггере типа AFTER INSERT (не INSTEAD)
А при этом придется позволить внешнему ключу в таблице компаний разрешить значение NULL.
Насколько это правильно?

Naf, так же в этом случае придется создавать аккаунт со значениями по умолчанию.
А представляете реакцию пользователя, когда он увидит не им созданный аккаунт с данными, совершенно несоответствующими реальной действительности?
Дублировать тоже не хотелось бы, но возможно именно в этом случае это лучший вариант.

divvInfernal V. Ravenвариант нужно выбирать исходя из потребностей и затрат
Полностью соглашусь. Пока что нет полного набора требований, например, непонятно, нужно хранить значения основных аккаунтов для исторических данных (скорее всего, да), или только для текущих. И еще что-то может вылезти, влияющее на решение.
Требования есть. Исторические данные об главных аккаунтах хранить не нужно. Есть компания, а у нее есть аккаунты, один из которых ВСЕГДА будет являться главным. Это совершенно точно и эти требования будут неизменны. Так что какие мысли? Как это будет сделать более оптимально? Заранее Вам благодарен :)

Infernal V. Ravenrsolanov,

я привел вам 3 варианта
чем не устраивают?
Решил дублировать. Большое всем спасибо за помощь :)