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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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