1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.

SQL - трабла с идешниками

Тема в разделе "Программирование", создана пользователем Mikle, 10.12.07.

  1. Mikle

    Mikle Активный участник

    1.318
    0
    Ситуация такова: есть несколько БД, в каждой из которых есть таблица Table1 состощая из двух полей: ID - идентификатор, и допустим DataName - string.

    Теперь ситуация такова: набор DataName для всех БД одинаков, но ID для определенного DataName для каждой БД индивидуальны.

    На пример:
    БД1:
    ID = 1 DataName = 'First Value'
    ID = 2 DataName = 'Second Value'
    ID = 3 DataName = 'Third Value'
    БД1:
    ID = 1 DataName = 'Second Value'
    ID = 2 DataName = 'Third Value'
    ID = 3 DataName = 'First Value'

    При этом на таблицу Tablr

    Внимание вопрос:
    как с наименьшими потерями сделать во всех таблицах Table1 (для всех баз) единую системы идентификации, чтобы значения ID совпадали для одинаковых DataName?

    Вот что пришло мне на ум:
    1. вариант решения: формируем эталон таблицы. В каждой БД сносим связи м/у Table1 и ост. таблицами, а потом апдейтим сначала зависимые таблицы, потом саму Table1 согласно эталону...
    2. рядом с ID приклеить ID1 - том самый уникальный ИДешник... НО! Это потребует перепревязки всех таблиц, а так же переработки всего клиента, что не есть хорошо...

    Может кто с подобной задачей сталкивался? Как еще можно извратится?
     
  2. svalx

    svalx Участник

    244
    0
    Мне больше первый вариант нравится. Только сначала наверное нужно проапдэйтить Table1 , потом связи новые привязывать...
     
  3. Mikle

    Mikle Активный участник

    1.318
    0
    svalx,
    а как ты после апдейта первой будешь апдейтить привязанные? По какому принципу? Ты ж связи утеряешь, по-моему...
     
  4. bivshii

    bivshii Активный участник

    753
    3
    В чем проблема?
    Update Baza2.dbo.Table1 SET ID =
    ( Select Id from Baza1.dbo.Table1 where Baza1.dbo.Table1.DataName = Baza1.dbo.Table1.DataName)
    при включенном каскадном обновлении
     
  5. jek

    jek Активный участник

    5.733
    0
    bivshii, если ID первичный ключ выполнить этого нельзя. В общем не понял в чем вопрос. Бери да делай. Операция несложная, если проблемы с ссылочными отношениями надо их решать соответственно. Плюс подумать что сделать, чтобы дальше такого не возникало.
     
  6. bivshii

    bivshii Активный участник

    753
    3
    jek, проверь. :-)

    CREATE TABLE [dbo].[T1](
    [Id] [int] NOT NULL,
    [TF] [varchar](50) COLLATE Cyrillic_General_CI_AS NOT NULL,
    CONSTRAINT [PK_T1] PRIMARY KEY CLUSTERED
    (
    [Id] ASC
    ) ON [PRIMARY]
    ) ON [PRIMARY]

    CREATE TABLE [dbo].[T2](
    [Id] [int] NOT NULL,
    [TF] [varchar](50) COLLATE Cyrillic_General_CI_AS NOT NULL,
    CONSTRAINT [PK_T2] PRIMARY KEY CLUSTERED
    (
    [Id] ASC
    ) ON [PRIMARY]
    ) ON [PRIMARY]

    Insert into dbo.T1 (Id, TF) values (1,'ИВАНОВ')
    Insert into dbo.T1 (Id, TF) values (2,'ПЕТРОВ')
    Insert into dbo.T1 (Id, TF) values (3,'СИДОРОВ')

    Insert into T2 (Id, TF) values (3,'ИВАНОВ')
    Insert into T2 (Id, TF) values (1,'ПЕТРОВ')
    Insert into T2 (Id, TF) values (2,'СИДОРОВ')

    UPDATE T2
    SET Id = (SELECT ID FROM T1 WHERE T1.TF = T2.TF)

    SELECT * FROM T2

    На самом деле, понятно, что в реальной базе ID - автоинкремент может быть и т.д. и придется повозиться побольше, снять автоинкременты, потом поставить. Но в пределах первого топика достаточно одной строки.
     
  7. AlTk

    AlTk Читатель

    10.699
    0
    bivshii,
    я бы вообще не советовал с каскадным обновлением связываться, а уж тому, кто такие вопросы задает, тем более.
     
  8. Mikle

    Mikle Активный участник

    1.318
    0
    bivshii,
    вот на счет каскадного я как-то даже не подумал, а идея хорошая :) Всем спасибо.

    jek,
    иногда приходится сталкиваться с уже разработанными проектами, в которых далеко не все предусмотрено :)
     
  9. bivshii

    bivshii Активный участник

    753
    3
    AlTk , а что плохого в каскадном обновлении?
    Руками навертеть можно гораздо круче. Правда, прежде чем идти базу править, лучше книжку прочитать. Или на SQL-EX потренироваться...
    А лучше и то и то.
     
  10. AlTk

    AlTk Читатель

    10.699
    0
    bivshii,
    я просто не понимаю зачем оно?
    в каких случаях нужно править первичные ключи, начиная с самого верха иерархии отношений?
     
  11. bivshii

    bivshii Активный участник

    753
    3
    Править за 5 лет ни разу не приходилось. Каскадное удаление само собой. Я вообще предпочитаю автоинкремент везде ставить. Но вот есть же задачи (см. выше :-) ) , в которых с каскадным обновлением проще
     
  12. AlTk

    AlTk Читатель

    10.699
    0
    bivshii,
    это неправильно спроектированные БД и/или неправильно поставленные задачи.
     
  13. bivshii

    bivshii Активный участник

    753
    3
    Да кто спорит. Хотя возможны варианты, можно выдумать что - нибудь типа загрузки данных из внешнего источника.Или например, если банковский счет - первичный ключ, а произошло, как когда-то, изменение 9-значного на 20-значный....
     
  14. Mikle

    Mikle Активный участник

    1.318
    0
    AlTk,
    приведу приемр задачи:
    изначально разрабатывается ПО, которое ставится в куче филиалов одной организаций обособленно... Проектируется БД, клиент, отчеты... Все работает, пашет и сено косит...

    ПО работает в течении нескольких лет, после этого заказчик говорит:
    "Программист, я хочу ля, чтобы я сидя в своем офисе мог сформировать любой отчет (а их ~150) сводный по всем базам...
    Причем отчет должен иметь туже форму, что печатают на местах (типа композитный отчет)... Да параметры отчета я хочу задать один раз и навсегда и чтоб по 20 баз сразу строилось с одним заданым параметром...
    А и чуть не забыл - сроку тебе две недели"...

    И тут программист (а он юзает фаст репорт) втыкает, что все dblookup combobox в отчетах завязаны на ID, и что выбрав однажды идешник, он должен быть уникальным для всех баз...

    Надо сказать что таблицы справочники имеют одну суть, но сущности могут быть с разными идентификаторами (забиты в разном порядке)...

    И вот тут-то и есть необходимость менять ключи...

    Ну как доходчивая сказка?
     
  15. AlTk

    AlTk Читатель

    10.699
    0
    Mikle,
    не нужно мне рассказывать сказки.
    я уже говорил: "это неправильно спроектированные БД и/или неправильно поставленные задачи."

    ПС. "... И вот тут-то и есть необходимость менять ключи ..."
    в школу. срочно!

    добавлено через 1 минуту
    "... а он юзает фаст репорт ..."
    да хоть черта лысого.
     
  16. Welcome

    Welcome Читатель

    5.409
    0
    AlTk, злой, ты, дядька!
     
  17. Mikle

    Mikle Активный участник

    1.318
    0
    AlTk,
    как бы там ни было проблема реально встала и ее пришлось решать. На мой взгляд найденый вариант был оптимальным исходя из трудозатрат. Если видишь более оптимальный скажи, если нет, то к сожалению, общие фразы типа "это неправильно спроектированные БД и/или неправильно поставленные задачи" проблеме ну ни как не помогают.
    Всем спасибо за помощь.
     
  18. Гость

    Гость Гость

    а не проще пока не разобрались нормально с БД не сделать логику в ПО?
    ну создайте таблицу соответствий ид-шников для всех БД на первое время.
     
  19. Mikle

    Mikle Активный участник

    1.318
    0
    Гость,
    проблема в том, что таблицы заполняюится клиентами. Соответственно предугадать какой ИДешник к чему будет относится не возможно... По-мимо этого есть ряд отчетов уже завязанных по запросам на данную таблицу и формируется композитная отчетность (это когда берется ИДешник из первой базы и затем применяется ко всем - если интересно объясню подробней)... Перестроить запросы всех отчетов? Слишком накладно.
     
  20. Гость

    Гость Гость


    если справочник общий, то должен существовать центр ответственности за его ведение. и он должен синхронизироваться по всем базам. без этого вам и замена ИД-ов не поможет, они в итоге опять расползутся.


    ээээ...а запросы тут причем?
    создайте список соответствия ИД одной второй третьей и т.д. базы и при переключении с базы на базу берите нужный для этой базы ид-ник(ориентируясь по первому) и передавайте параметром в запрос.
     
  21. Mikle

    Mikle Активный участник

    1.318
    0
    Гость,
    изначально не подразумевалось создание мультиотчетности. Поэтому справочник наполнялся пользователями в произвольном порядке. Теперь после нескольких лет эксплуатации необходимо синхронизировать справочник по всем базам, в чем и была задача...
    Ваше предложение со списком соответствия предполагает доработку отчетов, так как после того, как отчет был запущен вмешаться в его структуру ой как не просто... Тем более процедура по разовому апдейту ИДешников позволит провести переназначение всего один раз и тогда нет смысла в постоянном сверении с эталоном.