Конференция "Базы" » Версия базы sql [D7, MSSQL]
 
  • yurikon (06.12.11 17:54) [0]
    Возможно ли в базе где-то прописать версию подобно ехе-файлу?
    Для чего это нужно - при обновлении версии программы, надо проверить соответствует ли версия базы данных версии программы. Если нет, то обновить структуру базы.

    С уважением.
  • sniknik © (06.12.11 18:01) [1]
    версия базы не зависит от структуры... что наводит на мысль, что это твоя версия... т.е. не версия базы, а версия твоей структуры. ну и пиши ее куда сам хочешь определи табличку и проверяй в ней значение.
  • Омлет © (06.12.11 18:14) [2]
    Надо хранить версию базы в самой базе. А так же весь список миграций.
  • yurikon (06.12.11 18:23) [3]
    Это понятно, думал может более красивое решение есть.

    Еще вопрос, опять же про обновление своей БД. Программа сама создает новую структуру БД, но в старой БД остается пара таблиц с данными, которые надо перенести в новую БД. Использовать SELECt INTO не могу, так как при этом не переносятся индексы и триггеры. Дополнительная проблема в том, что новая БД должна быть создана в том же месте и с тем же именем, что старая.

    Пока в голове такой сценарий - копирую данные во временные таблицы в базе temp. Удаляю старую БД. Создаю новую. И в самом делфи в цикле переношу рекорды. Насколько это правильно? Или есть более грамотное решение?

    С уважением.
  • Омлет © (06.12.11 19:07) [4]
    Существующие таблицы мигрируют через ALTER TABLE. Индексы обновляют.
  • Inovet © (06.12.11 20:02) [5]
    > [3] yurikon   (06.12.11 18:23)

    А почему в существующей не делеть обновление структуры? Прочитал текущую версию, накатил обновление до следующей см.
    > [4] Омлет ©   (06.12.11 19:07)
    > Существующие таблицы мигрируют через ALTER TABLE. Индексы обновляют.
  • Ega23 © (06.12.11 23:03) [6]

    > Использовать SELECt INTO не могу, так как при этом не переносятся
    > индексы и триггеры.


    Индексы и триггеры - самостоятельные объекты БД, если чё.
    Они также создаются, изменяются и удаляются.
  • Медвежонок Пятачок © (07.12.11 14:07) [7]
    версию хранить можно, но не нужно.
    потому что.

    нужно просто проверять наличие нужных объектов перед их использованием и создавать их если объектов нет.
  • Ega23 © (07.12.11 14:26) [8]

    > нужно просто проверять наличие нужных объектов перед их
    > использованием и создавать их если объектов нет.


    Больно монстрообразный скрипт получится.
  • Омлет © (07.12.11 14:45) [9]

    > Медвежонок Пятачок ©   (07.12.11 14:07) [7]
    > версию хранить можно, но не нужно.потому что.нужно просто
    > проверять наличие нужных объектов перед их использованием
    > и создавать их если объектов нет.

    Это даже для простейших случаев не годится.
  • Ega23 © (07.12.11 14:51) [10]

    > Это даже для простейших случаев не годится.


    Смотря для какой СУБД.
    Например, тот же MSSQL не строго к зависимостям между объектами базы относится.
    Соответственно, я совершенно спокойно могу сначала обновить структуру таблиц, а потом пересоздать существующие ХП.
  • Медвежонок Пятачок © (07.12.11 15:32) [11]
    Это даже для простейших случаев не годится.

    Что не годится?

    Ну записал ты версию в таблицу.
    Затем в базе кто-то што-то изменил. Например удалил добавленное тобой поле.
    Ты запускаешься, смотришь, версия кошерная, начинаешь селектить.
    И тут облом.
    Поля нет.
    Что ты делаешь?
    Снова его добавляешь.
  • Медвежонок Пятачок © (07.12.11 15:37) [12]
    > Это даже для простейших случаев не годится.
    Смотря для какой СУБД.


    У меня была мультисерверная программа.
    В том смысле, что работала с ораклом, mssql, access, mysql и фб.
    И использовался именно такой подход.
    Очередная новая версия знала, что для нее должны быть созданы такие то новые поля и такие-то новые таблицы.
    Плюс она помнила всю историю предыдущих апдейтов БД.

    В результате можно было взять самый свежую версию и подсунуть ей самую старую базу.
    И программу это нимало не пугало.
  • Омлет © (07.12.11 16:45) [13]

    > Медвежонок Пятачок ©
    > Очередная новая версия знала, что для нее должны быть созданы
    > такие то новые поля и такие-то новые таблицы.Плюс она помнила
    > всю историю предыдущих апдейтов БД.

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


    > Затем в базе кто-то што-то изменил. Например удалил добавленное
    > тобой поле.

    Не должен никто в базу лезть, кроме приложения. Иначе ССЗБ и база испорчена. И я не говорил, что проводить миграции надо без проверок.
  • Медвежонок Пятачок © (07.12.11 16:59) [14]
    И как ты определял, какие апдейты уже проведены, а какие нет,

    я не апдейты проверял, а существование объектов бд, которые появились в ней после того, как разошлась версия программы №1
  • sniknik © (07.12.11 17:13) [15]
    > я не апдейты проверял, а существование объектов бд
    у меня тоже самое сделано, но с добавкой проверки версии база/"структуры (какой смысл запускать кучу проверок, если версия уже последняя...) после апдейта версия подымается до максимальной а тот момент.

    если кто то влез и сам что то наисправлял... то ССЗБ.
    а так удобно, да, весь апдейт это новый exe подложить, и не заботится о запуске каких то скриптов, их порядка (есть, видел, зависят от номера и запускаются строго по порядку, т.е. сначала проблем себе навыдумывают, а после "обновляторы" пишут...)
  • Ega23 © (07.12.11 17:13) [16]

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


    Что-то типа:


    if COLUMNPROPERTY(OBJECT_ID(N'[ISSCamera]'), 'SubAddr', 'precision') is NULL
    begin
    Print 'Добавить поле ISSCamera.SubAddr  - подадрес элемента модели';
    ALTER TABLE ISSCamera add SubAddr int NOT NULL default 0;
    end;
    go
    if COLUMNPROPERTY(OBJECT_ID(N'[ISSMonitor]'), 'SubAddr', 'precision') is NULL
    begin
    Print 'Добавить поле ISSMonitor.SubAddr  - подадрес элемента модели';
    ALTER TABLE ISSMonitor add SubAddr int NOT NULL default 0;
    end;
    go

    if exists (select 1
               from  sysobjects
              where  id = object_id('dbo.Abonents')
               and   type = 'U' and
               (COLUMNPROPERTY(OBJECT_ID(N'[Abonents]'), 'AbID', 'precision') is not NULL)
               )
      drop table dbo.Abonents
    go

    if exists (select 1
               from  sysobjects
              where  id = object_id('dbo.TaskAbPL')
               and   type = 'U')
      drop table dbo.TaskAbPL
    go

    if not exists (select 1
               from  sysobjects
              where  id = object_id('AbonentTyps')
               and   type = 'U')
    begin

     create table AbonentTyps (
      AbTypCod             int                            not null,
      AbTypNam             varchar(64)                    not null,
      AbTypLab             varchar(64)                    not null,
      AbTypOrd             int                            not null,
      AbTypMsk             tinyint                        not null,
      AbTypNot             varchar(255)                   not null,
      AbTypImg             image                          null,
      constraint PK_ABONENTTYPS primary key  (AbTypCod)
     );
     Print('Table created: AbonentTyps');
    end;
    go

  • Ega23 © (07.12.11 17:17) [17]

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


    Это хорошо, если ты можешь перегенерить все триггеры, вьюхи и прочие ХП одним чохом, не заморачиваясь на dependences.
    Тот же FB такое не позволяет. Точнее, приходится адски геммороится и патч-скрипт разрастается до совсем неприличных размеров (если его очень аккуратно и правильно "вести").
    Посему - патч до версии такой-то, а если таблица или поле не существуют, а также кто-то туда своими шаловливыми ручками влез - ССЗБ, sniknik © + 1
  • sniknik © (07.12.11 17:28) [18]
    > Посему - патч до версии такой-то
    я не проверяю версию патча... проверяю версию структуры, и обновляю единым... который одинаково подымет с версии 1 или с предпоследней до последней...
    думаю Медвежонок про то и говорит.
    а вот с версиями патчей, в одной проге поддержке "наелся по самое не могу"...
  • Омлет © (07.12.11 17:28) [19]
    Убиться можно с такими проверками. Тем более в реляционной структуре, когда один апдейт каскадно удаляет таблицы, обновляет другие и патчит третьи, а второй создает таблицу, создает зависимости и заполняет данные на основе предыдущего изменения (а не неизвестного состояния). Многие апдейты решают только последовательные миграции (которые бывают очень сложными), т.к. в сложных системах не сводится все к добавлению несвязанных столбцов и новых табличек.
 
Конференция "Базы" » Версия базы sql [D7, MSSQL]
Есть новые Нет новых   [134431   +10][b:0][p:0.002]