Проблема при записи в таблицу

← →
Uno-84 (2007-12-13 09:06) [0]

Здравствуйту! подскажите пожалуйста : я записываю сообщения в 2 таблицы, в одной(MSGBODIES) храниться текст сообщения и ID тела сообщения, в другой ID (MESSAGE_EXT) сообщения, отправитель, дата отправки, тип сообщения и ID Тела сообщения вот код:

with DataModule1.IBQShared do begin
SQL.Clear;
SQL.Add("insert into MSGBODIES ( MESSAGEBODY_ID, MESSAGE_TEXT) values (gen_id(MSGBODIES_GEN, 1),
:MESSAGE_TEXT)");
ParamByName("MESSAGE_TEXT").AsString := redtSender1.Text;

try
ExecSQL;
finally
end;
end;
with DataModule1.IBQShared do begin
SQL.Clear;
SQL.Add ("insert into MESSAGE_EXT( MESSAGE_ID, MESSAGE_SENDER, MESSAGE_SEND_DATE, MESSAGE_TYPE, MESSAGEBODY_ID) values (gen_id(GEN_MESSAGE_EXT_ID, 1), :MESSAGE_SENDER, :MESSAGE_SEND_DATE, :MESSAGE_TYPE,
:MESSAGEDODY_ID)");

try
ExecSQL;
finally
end;
end;
Проблемазаключаеться в следующем:
поле MESSAGEBODY_ID В таблице MESSAGE_EXT влешний ключ на поле
MESSAGEBODY_ID в таблице MSGBODIES, так вот при записи в таблицу MESSAGE_EXT начение поля MESSAGEBODY_ID ставиться значение NULL, а мне желательно что бы при записи значение поля совбодало с анологичным полем в MSGBODIES, подскажите пожалуйста строку или строки кода, которые помогли бы решить эту проблему. Заранее спасибо.

← →
Anatoly Podgoretsky © (2007-12-13 09:12) [1]

> Uno-84 (13.12.2007 09:06:00) [0]

Если не говорить про странный код, то вопрос только один, зачем нужна вторая таблица.

← →
Johnmen © (2007-12-13 09:16) [2]

и почему здесь finally?

← →
Uno-84 (2007-12-13 09:19) [3]

Код работает, честно, зачем вторая таблица не знаю))))) но она есть ))))) вот и прошу помощи в её заполнении

← →
Johnmen © (2007-12-13 09:40) [4]

> зачем вторая таблица не знаю

Это не твой код?

← →
Uno-84 (2007-12-13 09:55) [5]

Код писал я, а вот на счет таблицы MESSAGE_EXT мне сказали её создать, а смысл её создания ( вернее рационолность) мне трудно понять))))

← →
morgoth (2007-12-13 10:00) [6]

try
ExecSQL;
finally
end;
вот из-за таких кусков кода, оставленных в наследство, пришлось однажды убить полдня...

по всему код: зачем внешний ключ, зачем вторая таблица, где проставляются значения параметрам, что значит "код работает честно"?

← →
Johnmen © (2007-12-13 10:05) [7]

> а вот на счет таблицы MESSAGE_EXT мне сказали её создать

М.б. тогда наиболее логично спросить у них?

← →
Uno-84 (2007-12-13 10:17) [8]

Значения параметров прописанны в тригере таблицы

← →
Desdechado © (2007-12-13 10:23) [9]

Перед вставкой во вторую таблицу запросить полученное после первой вставки значние первичного ключа и использовать его.

← →
morgoth (2007-12-13 10:27) [10]

тогда объясни зачем ты пишешь такие запросы если все делает триггер?
>"insert into MESSAGE_EXT( MESSAGE_ID, MESSAGE_SENDER, >MESSAGE_SEND_DATE, MESSAGE_TYPE, MESSAGEBODY_ID) values >(gen_id(GEN_MESSAGE_EXT_ID, >1), :MESSAGE_SENDER, :MESSAGE_SEND_DATE, :MESSAGE_TYPE,
> :MESSAGEDODY_ID)"
ну и собсно по null в своем поле смотри код триггера

← →
Anatoly Podgoretsky © (2007-12-13 10:31) [11]

> Uno-84 (13.12.2007 09:55:05) [5]

> мне сказали её создать, а смысл её создания ( вернее рационолность) мне трудно понять))))

Это что бы ты помучился.

← →
ЮЮ © (2007-12-13 10:50) [12]

> > мне сказали её создать, а смысл её создания ( вернее рационолность)
> мне трудно понять))))

Вероятно, тела сообщений иногда бывают такие большие, что требуется сразу несколько отправителей, котрые его отсылают, ведь MSGBODIES связано с MESSAGE_EXT как 1..N :)

При работе с генераторами, ИМХО, следунт работать так:
подправить триггер так, чтобы он обращался к генератору только в том случае, когда Id IS NULL, а иначе бы доверял клиенту (тот и так обломится при попытке вставить запись с дублирующим ключом). Тогда при необходимости вставить записи в главную и подчиненную таблицу запроси на клиенте значение генератора и используй его. При вставке записей только главную таблицу можно "инсертить" и с NULL-евым Id-ом.

← →
morgoth (2007-12-13 10:59) [13]

>тела сообщений иногда бывают такие большие, что требуется сразу несколько отправителей

А решить это одной таблицей разве нельзя?

← →
ЮЮ © (2007-12-13 11:04) [14]

> [13] morgoth (13.12.07 10:59)
> >тела сообщений иногда бывают такие большие, что требуется
> сразу несколько отправителей
>
> А решить это одной таблицей разве нельзя?

MESSAGE_SENDER1, ..., MESSAGE_SENDER10 в приличном обществе решением не является :)

← →
ЮЮ © (2007-12-13 11:08) [15]

> Вероятно, тела сообщений иногда бывают такие большие, что
> требуется сразу несколько отправителей, котрые его отсылают,
> ведь MSGBODIES связано с MESSAGE_EXT как 1..N :)

Или это нафиг никому не нужное тело и его перемылают от одного отправителя к лругому, причем причину перерылки объяняюют одним числом MESSAGE_TYPE.

← →
morgoth (2007-12-13 11:22) [16]

>MESSAGE_SENDER1, ..., MESSAGE_SENDER10 в приличном обществе решением не является :)

а как в приличном обществе решают эту задачу с двумя таблицами когда есть 10 отправителей одного большого сообщения? ))) или в этом случае не будет MESSAGE_SENDER1, ..., MESSAGE_SENDER10???

← →
ЮЮ © (2007-12-13 11:25) [17]

Будет как у автора.
Исходя из его структуры я и смог сделать предположения [12] и [15] о сущностях предметной области.

← →
morgoth (2007-12-13 11:33) [18]

Мне кажется это будет то же самое и сендеры 1..10 никуда не денутся и в случае [12]
Хотя это уже не имеет значение, автор все равно получил свой ответ и спорить о решении неизвестной задачи не стоит.

← →
Sergey13 © (2007-12-13 11:44) [19]

> [16] morgoth (13.12.07 11:22)
> а как в приличном обществе решают эту задачу с двумя таблицами
> когда есть 10 отправителей одного большого сообщения? ))
> )

В приличном обществе в таком случае появляется третья таблица для отправителей сообщения.

← →
Anatoly Podgoretsky © (2007-12-13 11:49) [20]

А как они собирают обратно целое сообщение, ведь информации о части нет.

← →
ЮЮ © (2007-12-13 11:53) [21]

> [19] Sergey13 © (13.12.07 11:44)
> В приличном обществе в таком случае появляется третья таблица
> для отправителей сообщения.

MESSAGE_EXT.MESSAGE_SENDER, полагаю, и есть объект из таблицы отправителей MSGSENDERS.

т.е. MSGSENDERS и MSGBODIES связаны как M..N, а MESSAGE_EXT и есть таблица связи, которую было бы логичнее назвать MsgBodySenders

← →
ЮЮ © (2007-12-13 11:56) [22]

> [20] Anatoly Podgoretsky © (13.12.07 11:49)
> А как они собирают обратно целое сообщение, ведь информации
> о части нет.

Так это не сообщение на части разбито, а неделимое тело пересылается разными отправмиелями, причем без вдреса получателя.
Это, СПАМ-мащина, где получатель законспирирован под отправителя :)

> [21] ЮЮ © (13.12.07 11:53)
> MESSAGE_EXT.MESSAGE_SENDER, полагаю, и есть объект из таблицы
> отправителей MSGSENDERS.

Я имел в виду, что если бы у сообщения было несколько авторов, то логично было бы записывать их в отдельную таблицу, а не продить поля MESSAGE_SENDER_N.

← →
morgoth (2007-12-13 12:12) [24]

Не проще ли было бы завести поля ID и ParentID в основной таблице и перенести поле с телом сообщения туда же.
Либо оставить 2 таблицы, в таблицу с телами добавить поле с ID сообщения, а ссылку на тело из таблицы сообщений убрать.

← →
morgoth (2007-12-13 12:14) [25]

хотя опять же решение зависит от задачи, а она не ясна...

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

← →
morgoth (2007-12-13 13:04) [27]

помогли, понимаешь, спамеру юному... )))

> [26] Anatoly Podgoretsky © (13.12.07 12:53)

Например нечто вроде документообота с множеством авторов. Хотя это гадание на кофейной гуще уже начинается.

> Sergey13 (13.12.2007 13:17:28) [28]

Рассказать как делаются Многие ко Многим?

> [29] Anatoly Podgoretsky © (13.12.07 13:24)

А я в
> [19] Sergey13 © (13.12.07 11:44)

разве не про М2М писал?
Таблицы "Сообщения", "Авторы" (про которую в топике нет упоминаний, но которая видимо предполагается), и таблица связи сообщений и множества авторов.

ЗЫ: Автор смотался, а тут похоже холиварчик по домыслам намечается. 8-)

> Sergey13 (13.12.2007 13:49:30) [30]

У автора две таблицы и это не М2М
Да ладно тут можно ломать голову, нормализацию делал кто то некомпетентный.

Проблема при записи в таблицу Найти похожие ветки