Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
listtoview
Member

Откуда:
Сообщений: 2156
вот такой код считается приемлемым?
CREATE TABLE [dbo].[map_root] (
    [id]		INT             IDENTITY (1, 1) PRIMARY KEY CLUSTERED NOT NULL, 


был создан ПК:
PK__map_root__3213E83F105E1389
25 ноя 19, 11:20    [22024424]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
listtoview
Member

Откуда:
Сообщений: 2156
перепишу так:

CREATE TABLE [dbo].[map_root] (
    [id]		INT             IDENTITY (1, 1) NOT NULL,    
    [host]		VARCHAR (255)   NOT NULL,
    [hash]		VARCHAR (255)   NOT NULL,
    [created]	DATETIME NULL	DEFAULT(GETDATE()),
    CONSTRAINT [PK_map_root] PRIMARY KEY CLUSTERED 
    (
        [id] ASC
    ),
    CONSTRAINT [UQ_map_root] UNIQUE NONCLUSTERED
    (
        [host], [hash]
    )
);
25 ноя 19, 11:28    [22024434]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3148
listtoview,

Смысл имеет. Когда имя объекта заранее известно, с ним проще выполнять нужные действия. Ну там, переименовать, отключить / удалить, свойства изменить.

Пример из личной практики: допустим у вас есть система, которая установлена у ваших клиентов, причем хостится все не в облаке вашими силами, а on premises у них. Вы выпускаете новую версию, в которой нужно, ну скажем, добавить еще одно поле в существующий ключ.

Если имя констрейнта известно и одинаково у всех клиентов, то в change script, который новая версия приложения будет прогонять на клиентской базе при ее апгрейде, можно будет напрямую написать что-то типа (за синтаксис не ручаюсь, но для примера сойдет):
alter table dbo.Records drop constraint [UQ_Records_CreateDate];
go
alter table dbo.Records add constraint [UQ_Records_CreateDate_SomeFieldId] unique (CreateDate, SomeFieldId);
go

Если же уникальный ключ был создан безымянным, то сначала придется попариться и найти именно его имя в метаданных (что в некоторых случаях может быть крайне нетривиальной задачей), после чего выполнять приведенный выше код в динамическом SQL.

Я в свое время написал скрипт, который генерит вызовы sp_rename для переименования всех таких объектов, которые не соответствуют принятому соглашению. Перед сборкой релиза прогоняю скрипт на БД, потом из Visual Studio делаю Schema Compare с проектом базы, подтягиваю изменения в проект и готово. Проще, чем каждый раз руками все это набивать.
25 ноя 19, 11:57    [22024487]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4395
listtoview,

Если код (скрипт) генерируется, то да смысл есть.
25 ноя 19, 11:59    [22024490]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
listtoview,

Ну вот делаете вызов хранимки. И выдает вам ошибку:
"Violation of PRIMARY KEY constraint 'PK_map_root__3213E83F105E1389'"
или
"Violation of PRIMARY KEY constraint 'PK_map_root_host_hash"

Какое сообщение об ошибке вам легче и быстрее будет понять?
25 ноя 19, 12:24    [22024515]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
tunknown
Member

Откуда:
Сообщений: 748
Ennor Tiegael
Смысл имеет. Когда имя объекта заранее известно, с ним проще выполнять нужные действия. Ну там, переименовать, отключить / удалить, свойства изменить.

  • Смысл имеет, т.к. существенно проще становится работать с таблицами.
  • Смысл исчезает если правило не соблюдётся хоть один раз. Наоборот- становится хуже, т.к. содержимое может оказаться противоположным декларации.

    Дисциплину соблюдаете- именуете, не соблюдаете- лучше не именуйте.
  • 25 ноя 19, 12:50    [22024541]     Ответить | Цитировать Сообщить модератору
     Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
    iap
    Member

    Откуда: Москва
    Сообщений: 46954
    tunknown
    Ennor Tiegael
    Смысл имеет. Когда имя объекта заранее известно, с ним проще выполнять нужные действия. Ну там, переименовать, отключить / удалить, свойства изменить.

  • Смысл имеет, т.к. существенно проще становится работать с таблицами.
  • Смысл исчезает если правило не соблюдётся хоть один раз. Наоборот- становится хуже, т.к. содержимое может оказаться противоположным декларации.

    Дисциплину соблюдаете- именуете, не соблюдаете- лучше не именуйте.
  • Чего-то накрутили...
    Как это наименование объекта делает чего-то там хуже или лучше? Поясните, пожалуйста.
    25 ноя 19, 13:20    [22024588]     Ответить | Цитировать Сообщить модератору
     Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
    a_voronin
    Member

    Откуда: Москва
    Сообщений: 4395
    iap
    tunknown
    пропущено...

  • Смысл имеет, т.к. существенно проще становится работать с таблицами.
  • Смысл исчезает если правило не соблюдётся хоть один раз. Наоборот- становится хуже, т.к. содержимое может оказаться противоположным декларации.

    Дисциплину соблюдаете- именуете, не соблюдаете- лучше не именуйте.
  • Чего-то накрутили...
    Как это наименование объекта делает чего-то там хуже или лучше? Поясните, пожалуйста.


    Серверу та похер, че там за IX_8u90890890890890890890890890, а вот у человека в голове бардак.
    25 ноя 19, 13:22    [22024593]     Ответить | Цитировать Сообщить модератору
     Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
    Ennor Tiegael
    Member

    Откуда:
    Сообщений: 3148
    tunknown
  • Смысл исчезает если правило не соблюдётся хоть один раз. Наоборот- становится хуже, т.к. содержимое может оказаться противоположным декларации.

    Дисциплину соблюдаете- именуете, не соблюдаете- лучше не именуйте.
  • Т.е. если хаос возник в одном месте, то надо плодить его как можно больше? Я правильно понимаю?
    25 ноя 19, 14:30    [22024674]     Ответить | Цитировать Сообщить модератору
     Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
    tunknown
    Member

    Откуда:
    Сообщений: 748
    Ennor Tiegael
    Т.е. если хаос возник в одном месте, то надо плодить его как можно больше? Я правильно понимаю?
    Хаос выражается через тип bit, а не integer.
    25 ноя 19, 15:04    [22024727]     Ответить | Цитировать Сообщить модератору
     Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
    Ennor Tiegael
    Member

    Откуда:
    Сообщений: 3148
    tunknown
    Ennor Tiegael
    Т.е. если хаос возник в одном месте, то надо плодить его как можно больше? Я правильно понимаю?
    Хаос выражается через тип bit, а не integer.
    Т.е. поправить один случайно проскочивший безымянным констрейнт так же легко и просто, как и 20, и 100, и 5000 оных? Я правильно понимаю?
    25 ноя 19, 17:01    [22024864]     Ответить | Цитировать Сообщить модератору
     Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
    listtoview
    Member

    Откуда:
    Сообщений: 2156
    Ennor Tiegael
    tunknown
    пропущено...
    Хаос выражается через тип bit, а не integer.
    Т.е. поправить один случайно проскочивший безымянным констрейнт так же легко и просто, как и 20, и 100, и 5000 оных? Я правильно понимаю?

    не так же легко, а одинаково сложно

    Сообщение было отредактировано: 25 ноя 19, 18:23
    25 ноя 19, 18:22    [22024925]     Ответить | Цитировать Сообщить модератору
     Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 30829
    listtoview
    Ennor Tiegael
    Т.е. поправить один случайно проскочивший безымянным констрейнт так же легко и просто, как и 20, и 100, и 5000 оных? Я правильно понимаю?

    не так же легко, а одинаково сложно
    Менее сложно, пропорционально количеству.

    По такой логике не нужно давать осмысленных названий таблицам и полям, ведь всё равно кто то один раз ошибётся, а поправить название одной таблицы так же сложно, как и 1000 таблиц.
    Да и вообще программировать нельзя, ведь обязательно кто то сделает багу, а поправить багу так же сложно, как написать весь текст программы.
    25 ноя 19, 18:35    [22024936]     Ответить | Цитировать Сообщить модератору
     Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
    Владислав Колосов
    Member

    Откуда:
    Сообщений: 7407
    Если ТС задает такие вопросы, то о слове "рефакторинг" он даже и не слышал. Всё еще впереди, поздравляю!
    26 ноя 19, 11:15    [22025341]     Ответить | Цитировать Сообщить модератору
     Re: Есть ли смысл давать собственные названия ограничениям, ключам и тд?  [new]
    listtoview
    Member

    Откуда:
    Сообщений: 2156
    Владислав Колосов
    Если ТС задает такие вопросы, то о слове "рефакторинг" он даже и не слышал. Всё еще впереди, поздравляю!

    и как мне помешает рефакторингу такая запись?
      [created]	DATETIME NOT NULL	DEFAULT(GETDATE()),
    
    26 ноя 19, 11:41    [22025391]     Ответить | Цитировать Сообщить модератору
    Все форумы / Microsoft SQL Server Ответить