| 
 | 
| 
 
Вставляем строки с формированием ключевого поля по ключу другой таблицы 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Привет, All! Есть вопрос! Простая ситуация. Есть таблица (table1) с autoincrement полем (field11) типа, к примеру, integer, которое одновременно является Primary key'ем. Есть другая таблица (table2), у которой тоже есть поле integer (field21), также используемое в качестве Primary key'я, и одновременно являющееся Foreign key'ем по полю field11 в таблице table1. Такая вот простенькая связь, к примеру, один к одному, не важно. Задача: Вставить гопом в таблицу table2 кучу строк. Вопрос: Кто какими методами пользуется? Разрешается все: триггеры, процедуры, но желательно в стиле ASE. Спасибо всем заранее ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 03.03.2003, 19:16 | 
  
  
  
   | 
||
| 
 
Вставляем строки с формированием ключевого поля по ключу другой таблицы 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Извиняйте. Слово "гопом" обозначает "одним запросом" :) ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 03.03.2003, 19:29 | 
  
  
  
   | 
||
| 
 
Вставляем строки с формированием ключевого поля по ключу другой таблицы 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Откуда нужно вставлять (с клиента или из другой таблицы)? И что значит "одним запросом"? insert ... select ... ? ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 03.03.2003, 21:28 | 
  
  
  
   | 
||
| 
 
Вставляем строки с формированием ключевого поля по ключу другой таблицы 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Запросом INSERT INTO ... SELECT FROM .... Конкретная задача такая - перенести данные из таблиц датабазы на Access в таблицы датабазы на ASA или ASE. Структура таблиц, разумеется, разная. Ключевые поля при записи данных должны формироваться на принимающей стороне автоинкрементом. Наиболее важный момент - скорость переноса данных ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 04.03.2003, 11:10 | 
  
  
  
   | 
||
| 
 
Вставляем строки с формированием ключевого поля по ключу другой таблицы 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  > "Ключевые поля при записи данных должны формироваться на принимающей стороне автоинкрементом" Т.е. получается что в аксессе ключевых полей нет? Или все-таки есть? И откуда взялось требование вставки через INSERT INTO ... SELECT FROM ....? IMHO выгрузить данные из аксеса в текстовые файлы и потом загрузить в сайбэйз через bcp было бы быстрее. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 04.03.2003, 19:11 | 
  
  
  
   | 
||
| 
 
Вставляем строки с формированием ключевого поля по ключу другой таблицы 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Я, конечно, могу рассказать все предысторию вопроса, но для данной конкретной задачки это совсем неважно. Подойдем к ней более абстрактно. Итак, задачка. Есть table1. Ее задача - формировать и хранить глобальные идентификаторы неких объектов. Как формировать идентификаторы? Допустим автоинкрементом. Далее. Есть несколько других таблиц (table11, table12, table13 ...), в которых и лежат собственно эти объекты. В каждой таблице - свой тип объектов. Идентификатором каждого объекта является идентификатор из таблицы table1. Нужно заполнить эти таблицы объектов из некоего абстрактного хранилища. Пофигу, есть там свои идентификаторы у объектов в этом хранилище или нет. Может есть, может нет, а если и есть, то там они свои, и нас не интересуют. Важно только, что список объектов каждого типа из этого хранилища можно заполучить с помощью SELECT'a. Способ раз: рисуем процедуру, в которой получаем курсор на нужную коллекцию объектов, перебираем их по очереди, для каждого получаем из table1 идентификатор и сохраняем объект с этим идентификатором в соответствующей этому объекту таблице. Способ два: рисуем для каждой из таблиц table11, table12 и т.д. триггер, который перед вставкой объекта в соответствующей таблице получает идентификатор этого объекта из table1. В этом случае все объекты в нужную таблицу можно запихнуть одним запросом типа INSERT INTO ... SELECT FROM... Мне этот способ кажется более элегантным, чем первый. Вот и хотелось бы выяснить, существует ли третий способ, такой же элегантный, как второй, но... по-другому. Ну, может без использования триггеров. Скажем, для бесплатной версии MySQL, в которой, как известно, триггерами не пахнет. ЗЫ Интересно, а есть все-таки в Access'е ключевые поля? Или нет? :-) ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 05.03.2003, 18:50 | 
  
  
  
   | 
||
| 
 
Вставляем строки с формированием ключевого поля по ключу другой таблицы 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  >Способ раз ... С этим все понятно > Способ два ... триггер, который перед вставкой объекта в соответствующей > таблице получает идентификатор этого объекта из table1 А вот здесь не ясно как (на основании чего) триггер будет связывать объект с его идентификатором. Если критерий для этого все-таки имеется, то можно просто загрузить данные в таблицы 11, 12, 13 ... не специфицируя идентификаторы, а потом уже связать их с table1 отдельным апдэйтом. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 05.03.2003, 20:16 | 
  
  
  
   | 
||
| 
 
Вставляем строки с формированием ключевого поля по ключу другой таблицы 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Ну, в качестве примера  для ASA можно предложить следующее: table1: CREATE TABLE "DBA"."table1" ( "OBJECT_ID" integer NOT NULL DEFAULT autoincrement, "OBJECT_TYPE" char(20) NOT NULL DEFAULT 0, PRIMARY KEY ("OBJECT_ID") WITH HASH SIZE 10 ) table11: CREATE TABLE "DBA"."table11" ( "OBJECT_ID" integer NOT NULL, "OBJECT_NAME" char(20) NULL DEFAULT 'ObjName', PRIMARY KEY ("OBJECT_ID") WITH HASH SIZE 10 ) Связываем table1 и table11: ALTER TABLE "DBA"."table11" ADD FOREIGN KEY "table1_fk" ("OBJECT_ID") REFERENCES "DBA"."table1" ("OBJECT_ID") on delete cascade on update cascade WITH HASH SIZE 10 Добавляем для table11 триггер: create trigger dba.add_object before insert order 1 on DBA.table11 referencing new as new_object for each row begin insert into DBA.table1(OBJECT_TYPE) values('Type1'); set new_object.OBJECT_ID=@@identity end Теперь в принципе можно для теста выполнить что-то типа: INSERT INTO "DBA"."table11" ( OBJECT_NAME ) VALUES ( 'MyName' ) но в принципе можно попробовать и INSERT INTO "DBA"."table11" SELECT FROM ... ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 06.03.2003, 15:07 | 
  
  
  
   | 
||
| 
 
Вставляем строки с формированием ключевого поля по ключу другой таблицы 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Криво это все как-то. Даже с точки зрения нормализации. Зачем вообще нужно разделять объекты на разные таблицы. Не проще ли свалить все в одну, в которую добавить поле типа объекта. А если надо потом их по типам разделять (например из соображений безопасности) использовать вью. Впрочем, это мое личное мнение. Подробностей почему Вы делаете именно так я ведь не знаю. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 06.03.2003, 19:16 | 
  
  
  
   | 
||
| 
 | 

start [/forum/topic.php?fid=55&fpage=136&tid=2014947]:  | 
    0ms | 
get settings:  | 
    10ms | 
get forum list:  | 
    13ms | 
check forum access:  | 
    4ms | 
check topic access:  | 
    4ms | 
track hit:  | 
    47ms | 
get topic data:  | 
    13ms | 
get forum data:  | 
    3ms | 
get page messages:  | 
    75ms | 
get tp. blocked users:  | 
    2ms | 
| others: | 243ms | 
| total: | 414ms | 

| 0 / 0 | 

    Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
    
    
    «На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
    
    
    ... ля, ля, ля ...