Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / "Ручной" суррогатный ключ. / 23 сообщений из 23, страница 1 из 1
27.07.2012, 10:49
    #37894937
livvan
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
Добрый день.
Мы заказали систему документооборота некоему внешнему исполнителю.
Т.к. мне в будущем эту базу рефакторить и сопровождать (на данный момент это делается связкой Access + MS SQL), то активно общаюсь с разработчиком о том, что и как делается.

Разработчик выдвинул внезапное решение использовать "вручную" сделанный в vba-коде индекс, вместо имеющегося автоматического, мотивируя это тем, что если из базы с автоматически сформированными индексами нужно будет удалить данные, потребуется её переносить или изменять структуру, то связи буду разрушены.

Это решение действительно является ошибочным и просто странным, или я просто чего-то не понимаю?
...
Рейтинг: 0 / 0
27.07.2012, 10:57
    #37894958
Программист-Любитель
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
Это странное ошибочное решения. Я - разработчик БД на такой же связке во всех таблицах использую автоинкрементальный ПК (Суррогатный ключ). В великом противостоянии Естественные ключи - против Суррогатных я давно перешел на сторону суррогатных.
...
Рейтинг: 0 / 0
27.07.2012, 11:04
    #37894969
vadiminfo
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
livvanДобрый день.
Мы заказали систему документооборота некоему внешнему исполнителю.
Т.к. мне в будущем эту базу рефакторить и сопровождать (на данный момент это делается связкой Access + MS SQL), то активно общаюсь с разработчиком о том, что и как делается.

Разработчик выдвинул внезапное решение использовать "вручную" сделанный в vba-коде индекс, вместо имеющегося автоматического, мотивируя это тем, что если из базы с автоматически сформированными индексами нужно будет удалить данные, потребуется её переносить или изменять структуру, то связи буду разрушены.

Это решение действительно является ошибочным и просто странным, или я просто чего-то не понимаю?
Наверное, "просто странным", поскоку он на то и суррогатный, что его значение не имеет смысла. Однако, странность в том, что теперь, если нуно буит заносить без Васика, то нужно буит учитвать этот нюанс, что там в Васике возможно какие-то правила заполнения. А перенос, изменение структуры и не разрушение связей как бы в общем случае не являются не разрешимой задачей для БД и без Васика в общем случае.
Возможно, они исходят из того, что с БД буит работать тока их программа. Но такие предположения, наверное, выглядят как излишние ограничения для БД: сама идея БД быть предназначенной для разных программ в общем слуячае.
...
Рейтинг: 0 / 0
27.07.2012, 11:48
    #37895043
Cane Cat Fisher
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
livvanесли из базы с автоматически сформированными индексами нужно будет удалить данные, потребуется её переносить или изменять структуру, то связи буду разрушены.

Во-первых, я не вполне осознал, в чем именно неотвратимый ужас обычных ключей. Что означает "связи будут разрушены", почему это произойдет, если поля заполнялись автоматически, и почему этого не произойдет, если поля заполнялись с клиента?

livvan"вручную" сделанный в vba-коде индекс

Во-вторых, когда я слышу о заполнении ключей с клиента, я сильно подозреваю неработоспособность в многопользовательском режиме. Не 100% утверждаю, но подозреваю сильно. Попросите автора показать код?
...
Рейтинг: 0 / 0
27.07.2012, 12:00
    #37895065
livvan
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
Cane Cat Fisher,

автор Что означает "связи будут разрушены", почему это произойдет, если поля заполнялись автоматически, и почему этого не произойдет, если поля заполнялись с клиента?
Насколько я понял, по мнению "разработчика", автоматически генерированные индексы будут заново заполнятся и при этом будут ломаться связи.
Например: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2.

авторя сильно подозреваю неработоспособность в многопользовательском режиме.
Ну этот вопрос решаем, но требует опять же дополнительного кода на клиенте, который будет обрабатывать отказы.
...
Рейтинг: 0 / 0
27.07.2012, 12:15
    #37895101
vadiminfo
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
livvanНапример: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2.

А не автоматический в Васике по какому правилу в общем случае узнает, у какой записи было 3 а у какой 2? Как он их ваообще отличает записи то? Таблиц сотни, записей тысчи?
...
Рейтинг: 0 / 0
27.07.2012, 12:18
    #37895105
Кот Матроскин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
livvan,

Обоснование во всяком случае точно странное. Либо человек слабо себе представляет, как работает MS SQL Server, либо
дурочку гонит.
...
Рейтинг: 0 / 0
27.07.2012, 12:33
    #37895140
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
livvanНасколько я понял, по мнению "разработчика", автоматически генерированные индексы будут заново заполнятся и при этом будут ломаться связи.
Например: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2.Нет, такого не произойдёт, у записи 3 индекс останется 3.
...
Рейтинг: 0 / 0
27.07.2012, 13:17
    #37895237
Сергей Васкецов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
alexeyvglivvanНасколько я понял, по мнению "разработчика", автоматически генерированные индексы будут заново заполнятся и при этом будут ломаться связи.
Например: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2.Нет, такого не произойдёт, у записи 3 индекс останется 3.
Более того, новая запись будет иметь ID 4, а не 2.

Резюме: MSSQL имеет достаточно средств для генерации значений суррогатного PK своими силами. Хоть identity (при необхоидмости и insert ему можно сделать, например при крайне хитрой репликации руками, или правке ошибок), хоть guid. А "вручную" сделанный в vba-коде индекс - бред и провокация.
...
Рейтинг: 0 / 0
27.07.2012, 13:33
    #37895269
Кот Матроскин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
Сергей ВаскецовА "вручную" сделанный в vba-коде индекс - бред и провокация.

Скорее всего, это не "бред и провокация", а попытка намертво привязать базу к клиентской программе, чтобы работать с базой помимо этого конкретного клиента было затруднительно.
...
Рейтинг: 0 / 0
27.07.2012, 13:42
    #37895288
Бредятина
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
livvanНасколько я понял, по мнению "разработчика", автоматически генерированные индексы будут заново заполнятся и при этом будут ломаться связи.
Например: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2.

Главное, что Вам нужно понять: в реляционных системах принципиально нет идентификации объектов. То есть, нет никаких ID. А есть просто объявление полей ключами (ограничения целостности). Настоящий ID не является принципиально "полем таблицы", и никуда не "сдвигается":) Впрочем, и Вашем примере 3 не сменится на 2, конечно же:) Иначе это вообще не БД:)
...
Рейтинг: 0 / 0
27.07.2012, 13:46
    #37895301
Cane Cat Fisher
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
Кот МатроскинСкорее всего, это не "бред и провокация", а попытка намертво привязать базу к клиентской программе, чтобы работать с базой помимо этого конкретного клиента было затруднительно.

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

Я полагаю, код для получения идентификаторов на клиентской стороне худо-бедно уже написан. Да еще, наверное, внутри какой-то своей огромной библиотеки (не с нуля же взялся исполнитель за заказ, наработки есть). А использовать identify - это же надо поисследовать вопрос "а как же тогда получить на клиенте сгенеренное на сервере значение", да библиотеку поправить во многих местах. Геморрой, лень. Вот и грузит клиента небылицами.
...
Рейтинг: 0 / 0
27.07.2012, 15:11
    #37895549
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
Гоните нах, livvan, тупоголовых ламеров. Судя по приведенному фрагменту, они вам напишут геморрой.
...
Рейтинг: 0 / 0
27.07.2012, 16:01
    #37895666
livvan
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
Всем спасибо, в общем уже достаточно.

Программист-Любитель,
К вам, как к человеку работающего с аналогичной связкой ещё вопрос: SQL базу вы делаете сразу на сервере, или сначала собираете в Access, а потом "поднимаете" на сервер?
...
Рейтинг: 0 / 0
27.07.2012, 16:11
    #37895697
dvim
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
livvan,
Базу лучше сразу на сервере делать.

По теме - такие заполнение id на клиенте имеет смысл, если делать реплицируемые системы. (Синхронизация офисов)
Но - просто в качестве ключа тогда надо использовать guid. (В принципе, его на vba можно генерить)
Если используется guid, то имхо ничего страшного. Вполне вероятно, что это разумное решение.
(Не зря Ms во многих продуктах уже вовсю использует только guid. )
...
Рейтинг: 0 / 0
27.07.2012, 17:09
    #37895823
tanglir
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
livvanНасколько я понял, по мнению "разработчика", автоматически генерированные индексы будут заново заполнятся и при этом будут ломаться связи.
Например: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2.бить розробоччега головой апстену, пока он не уяснит, что такое автоинкремент/идентити и как оно работает.
Cane Cat FisherНе стоит искать злой умысел там, где все можно объяснить обычным идиотизмом.золотые слова.
...
Рейтинг: 0 / 0
27.07.2012, 17:20
    #37895840
Программист-Любитель
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
livvanВсем спасибо, в общем уже достаточно.

Программист-Любитель,
К вам, как к человеку работающего с аналогичной связкой ещё вопрос: SQL базу вы делаете сразу на сервере, или сначала собираете в Access, а потом "поднимаете" на сервер?
У меня классическая двузвенка MS SQL 2005/8 + Access ADP 2003/7/10 - работают все варианты. Базу серверный код веду в Visual Studio. Клиентскую часть - на собственной фреймворке а аксесе. Благодаря адепешному фреймворку (хи-хи) все прикладный формы можно не программировать, а настраивать. Разнообразные пользовательские формы строятся на базе типовых форм - табличной, формы-карточка, формы-структура эксплорер лайк и их сочетаний. Интерфейс построен на библиотеке вебеашных классов (хи-хи). Скорость разработки - высокая.
...
Рейтинг: 0 / 0
13.08.2012, 13:17
    #37914385
Критик
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
dvimПо теме - такие заполнение id на клиенте имеет смысл, если делать реплицируемые системы. (Синхронизация офисов)

В этом случае в таблицу просто добавляется поле "Ключ офиса". И все.
...
Рейтинг: 0 / 0
13.08.2012, 14:04
    #37914465
vadiminfo
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
КритикВ этом случае в таблицу просто добавляется поле "Ключ офиса". И все.
Такое влияние репликации на структуру табиц, скорее всего, может выглядеть как искажение: если таблица про автомобили, к примеру, то у них нет никаких ключей офиса, а тока ключи зажигания.
Так или иначе такая плата за репликацуию, может выглядеть, чрезмерным замусореванием для тех кто считает что в таблицах не должно быть ничего кроме свойств сущностей предметной области.
...
Рейтинг: 0 / 0
13.08.2012, 14:25
    #37914513
Кот Матроскин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
vadiminfoТакое влияние репликации на структуру табиц, скорее всего, может выглядеть как искажение: если таблица про автомобили, к примеру, то у них нет никаких ключей офиса, а тока ключи зажигания.
Так или иначе такая плата за репликацуию, может выглядеть, чрезмерным замусореванием для тех кто считает что в таблицах не должно быть ничего кроме свойств сущностей предметной области.

Суррогатный ключ по опрелелению не сущность предметной области, так что таким пуританам вообще стоит обходиться без него :)
Вмдеть принципиальную разницу между суррогатным ключом из одного поля и из двух - имхо странно.
...
Рейтинг: 0 / 0
13.08.2012, 15:27
    #37914653
vadiminfo
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
Кот МатроскинСуррогатный ключ по опрелелению не сущность предметной области, так что таким пуританам вообще стоит обходиться без него :)

Вы хотели сказать не свойство сущности.
Ну это известный его не достаток, с которым приходится мириться. Но он все же юзается ради поддержки основной информации в БД, например, связей. А репликация к информационному содержанию отношения совсем не имеет.
Не пуританские проггеры и вставлябют в БД что попало. Свои там переменные из клиентов.

Кот МатроскинВмдеть принципиальную разницу между суррогатным ключом из одного поля и из двух - имхо странно.
Разница между одни полем и двумя есть все же: чем больше полей не относящихся к свойсвам сущностей, тем больше структурное несоотвествие.
К примеру, разница между суррогатом из одного и 10 полей тоже странная?
Возможно, для кого-то нет. А для кого-то и два - редкостный мусор в БД.
...
Рейтинг: 0 / 0
14.08.2012, 01:22
    #37915314
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
livvanРазработчик выдвинул внезапное решение использовать "вручную" сделанный в vba-коде индекс, вместо имеющегося автоматического, мотивируя это тем, что если из базы с автоматически сформированными индексами нужно будет удалить данные, потребуется её переносить или изменять структуру, то связи буду разрушены.
1. Я не вижу, каким образом в одной и той же БД с одними и теми же данными удаление разрушит либо не разрушит базу в зависимости от способа заполнения поля. Бред какой-то.

2. В нормальной БД данные не удаляются. Максимум - переносятся в архив.

3. И изменение структуры тоже нигде и никогда связей не разрушает.

Вывод - разработчик хотя бы школу-то окончил?

livvanНасколько я понял, по мнению "разработчика", автоматически генерированные индексы будут заново заполнятся и при этом будут ломаться связи. Например: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2.
И сколько вы ему уже заплатили?

П.С. Где вы таких находить-то ухитряетесь?

КритикВ этом случае в таблицу просто добавляется поле "Ключ офиса". И все.
Это утверждение отлично смотрелось бы в книге теоретика, никогда не опускавшегося до практики. Как тот филин - помните? - "я стратегией занимаюсь". На практике же это "и всё" означает как минимум составной ключ. Чего уже достаточно, чтобы с позором похоронить эту идею.

Ключ офиса, конечно, внести не помешает. Но "добавляется поле" - худшее из возможных решений. Ну или близкое к худшему.
...
Рейтинг: 0 / 0
14.08.2012, 08:30
    #37915400
vadiminfo
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"Ручной" суррогатный ключ.
softwarerЭто утверждение отлично смотрелось бы в книге теоретика, ....
Сам Доктор Кодд обзавидовался бы читая из такой теретический книги.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / "Ручной" суррогатный ключ. / 23 сообщений из 23, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]