|
|
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
Добрый день. Мы заказали систему документооборота некоему внешнему исполнителю. Т.к. мне в будущем эту базу рефакторить и сопровождать (на данный момент это делается связкой Access + MS SQL), то активно общаюсь с разработчиком о том, что и как делается. Разработчик выдвинул внезапное решение использовать "вручную" сделанный в vba-коде индекс, вместо имеющегося автоматического, мотивируя это тем, что если из базы с автоматически сформированными индексами нужно будет удалить данные, потребуется её переносить или изменять структуру, то связи буду разрушены. Это решение действительно является ошибочным и просто странным, или я просто чего-то не понимаю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 10:49 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
Это странное ошибочное решения. Я - разработчик БД на такой же связке во всех таблицах использую автоинкрементальный ПК (Суррогатный ключ). В великом противостоянии Естественные ключи - против Суррогатных я давно перешел на сторону суррогатных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 10:57 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
livvanДобрый день. Мы заказали систему документооборота некоему внешнему исполнителю. Т.к. мне в будущем эту базу рефакторить и сопровождать (на данный момент это делается связкой Access + MS SQL), то активно общаюсь с разработчиком о том, что и как делается. Разработчик выдвинул внезапное решение использовать "вручную" сделанный в vba-коде индекс, вместо имеющегося автоматического, мотивируя это тем, что если из базы с автоматически сформированными индексами нужно будет удалить данные, потребуется её переносить или изменять структуру, то связи буду разрушены. Это решение действительно является ошибочным и просто странным, или я просто чего-то не понимаю? Наверное, "просто странным", поскоку он на то и суррогатный, что его значение не имеет смысла. Однако, странность в том, что теперь, если нуно буит заносить без Васика, то нужно буит учитвать этот нюанс, что там в Васике возможно какие-то правила заполнения. А перенос, изменение структуры и не разрушение связей как бы в общем случае не являются не разрешимой задачей для БД и без Васика в общем случае. Возможно, они исходят из того, что с БД буит работать тока их программа. Но такие предположения, наверное, выглядят как излишние ограничения для БД: сама идея БД быть предназначенной для разных программ в общем слуячае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 11:04 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
livvanесли из базы с автоматически сформированными индексами нужно будет удалить данные, потребуется её переносить или изменять структуру, то связи буду разрушены. Во-первых, я не вполне осознал, в чем именно неотвратимый ужас обычных ключей. Что означает "связи будут разрушены", почему это произойдет, если поля заполнялись автоматически, и почему этого не произойдет, если поля заполнялись с клиента? livvan"вручную" сделанный в vba-коде индекс Во-вторых, когда я слышу о заполнении ключей с клиента, я сильно подозреваю неработоспособность в многопользовательском режиме. Не 100% утверждаю, но подозреваю сильно. Попросите автора показать код? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 11:48 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
Cane Cat Fisher, автор Что означает "связи будут разрушены", почему это произойдет, если поля заполнялись автоматически, и почему этого не произойдет, если поля заполнялись с клиента? Насколько я понял, по мнению "разработчика", автоматически генерированные индексы будут заново заполнятся и при этом будут ломаться связи. Например: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2. авторя сильно подозреваю неработоспособность в многопользовательском режиме. Ну этот вопрос решаем, но требует опять же дополнительного кода на клиенте, который будет обрабатывать отказы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 12:00 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
livvanНапример: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2. А не автоматический в Васике по какому правилу в общем случае узнает, у какой записи было 3 а у какой 2? Как он их ваообще отличает записи то? Таблиц сотни, записей тысчи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 12:15 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
livvan, Обоснование во всяком случае точно странное. Либо человек слабо себе представляет, как работает MS SQL Server, либо дурочку гонит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 12:18 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
livvanНасколько я понял, по мнению "разработчика", автоматически генерированные индексы будут заново заполнятся и при этом будут ломаться связи. Например: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2.Нет, такого не произойдёт, у записи 3 индекс останется 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 12:33 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
alexeyvglivvanНасколько я понял, по мнению "разработчика", автоматически генерированные индексы будут заново заполнятся и при этом будут ломаться связи. Например: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2.Нет, такого не произойдёт, у записи 3 индекс останется 3. Более того, новая запись будет иметь ID 4, а не 2. Резюме: MSSQL имеет достаточно средств для генерации значений суррогатного PK своими силами. Хоть identity (при необхоидмости и insert ему можно сделать, например при крайне хитрой репликации руками, или правке ошибок), хоть guid. А "вручную" сделанный в vba-коде индекс - бред и провокация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 13:17 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовА "вручную" сделанный в vba-коде индекс - бред и провокация. Скорее всего, это не "бред и провокация", а попытка намертво привязать базу к клиентской программе, чтобы работать с базой помимо этого конкретного клиента было затруднительно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 13:33 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
livvanНасколько я понял, по мнению "разработчика", автоматически генерированные индексы будут заново заполнятся и при этом будут ломаться связи. Например: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2. Главное, что Вам нужно понять: в реляционных системах принципиально нет идентификации объектов. То есть, нет никаких ID. А есть просто объявление полей ключами (ограничения целостности). Настоящий ID не является принципиально "полем таблицы", и никуда не "сдвигается":) Впрочем, и Вашем примере 3 не сменится на 2, конечно же:) Иначе это вообще не БД:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 13:42 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинСкорее всего, это не "бред и провокация", а попытка намертво привязать базу к клиентской программе, чтобы работать с базой помимо этого конкретного клиента было затруднительно. Не стоит искать злой умысел там, где все можно объяснить обычным идиотизмом. Я полагаю, код для получения идентификаторов на клиентской стороне худо-бедно уже написан. Да еще, наверное, внутри какой-то своей огромной библиотеки (не с нуля же взялся исполнитель за заказ, наработки есть). А использовать identify - это же надо поисследовать вопрос "а как же тогда получить на клиенте сгенеренное на сервере значение", да библиотеку поправить во многих местах. Геморрой, лень. Вот и грузит клиента небылицами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 13:46 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
Гоните нах, livvan, тупоголовых ламеров. Судя по приведенному фрагменту, они вам напишут геморрой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 15:11 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
Всем спасибо, в общем уже достаточно. Программист-Любитель, К вам, как к человеку работающего с аналогичной связкой ещё вопрос: SQL базу вы делаете сразу на сервере, или сначала собираете в Access, а потом "поднимаете" на сервер? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 16:01 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
livvan, Базу лучше сразу на сервере делать. По теме - такие заполнение id на клиенте имеет смысл, если делать реплицируемые системы. (Синхронизация офисов) Но - просто в качестве ключа тогда надо использовать guid. (В принципе, его на vba можно генерить) Если используется guid, то имхо ничего страшного. Вполне вероятно, что это разумное решение. (Не зря Ms во многих продуктах уже вовсю использует только guid. ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 16:11 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
livvanНасколько я понял, по мнению "разработчика", автоматически генерированные индексы будут заново заполнятся и при этом будут ломаться связи. Например: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2.бить розробоччега головой апстену, пока он не уяснит, что такое автоинкремент/идентити и как оно работает. Cane Cat FisherНе стоит искать злой умысел там, где все можно объяснить обычным идиотизмом.золотые слова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 17:09 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
livvanВсем спасибо, в общем уже достаточно. Программист-Любитель, К вам, как к человеку работающего с аналогичной связкой ещё вопрос: SQL базу вы делаете сразу на сервере, или сначала собираете в Access, а потом "поднимаете" на сервер? У меня классическая двузвенка MS SQL 2005/8 + Access ADP 2003/7/10 - работают все варианты. Базу серверный код веду в Visual Studio. Клиентскую часть - на собственной фреймворке а аксесе. Благодаря адепешному фреймворку (хи-хи) все прикладный формы можно не программировать, а настраивать. Разнообразные пользовательские формы строятся на базе типовых форм - табличной, формы-карточка, формы-структура эксплорер лайк и их сочетаний. Интерфейс построен на библиотеке вебеашных классов (хи-хи). Скорость разработки - высокая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2012, 17:20 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
dvimПо теме - такие заполнение id на клиенте имеет смысл, если делать реплицируемые системы. (Синхронизация офисов) В этом случае в таблицу просто добавляется поле "Ключ офиса". И все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2012, 13:17 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
КритикВ этом случае в таблицу просто добавляется поле "Ключ офиса". И все. Такое влияние репликации на структуру табиц, скорее всего, может выглядеть как искажение: если таблица про автомобили, к примеру, то у них нет никаких ключей офиса, а тока ключи зажигания. Так или иначе такая плата за репликацуию, может выглядеть, чрезмерным замусореванием для тех кто считает что в таблицах не должно быть ничего кроме свойств сущностей предметной области. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2012, 14:04 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
vadiminfoТакое влияние репликации на структуру табиц, скорее всего, может выглядеть как искажение: если таблица про автомобили, к примеру, то у них нет никаких ключей офиса, а тока ключи зажигания. Так или иначе такая плата за репликацуию, может выглядеть, чрезмерным замусореванием для тех кто считает что в таблицах не должно быть ничего кроме свойств сущностей предметной области. Суррогатный ключ по опрелелению не сущность предметной области, так что таким пуританам вообще стоит обходиться без него :) Вмдеть принципиальную разницу между суррогатным ключом из одного поля и из двух - имхо странно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2012, 14:25 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинСуррогатный ключ по опрелелению не сущность предметной области, так что таким пуританам вообще стоит обходиться без него :) Вы хотели сказать не свойство сущности. Ну это известный его не достаток, с которым приходится мириться. Но он все же юзается ради поддержки основной информации в БД, например, связей. А репликация к информационному содержанию отношения совсем не имеет. Не пуританские проггеры и вставлябют в БД что попало. Свои там переменные из клиентов. Кот МатроскинВмдеть принципиальную разницу между суррогатным ключом из одного поля и из двух - имхо странно. Разница между одни полем и двумя есть все же: чем больше полей не относящихся к свойсвам сущностей, тем больше структурное несоотвествие. К примеру, разница между суррогатом из одного и 10 полей тоже странная? Возможно, для кого-то нет. А для кого-то и два - редкостный мусор в БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2012, 15:27 |
|
||
|
"Ручной" суррогатный ключ.
|
|||
|---|---|---|---|
|
#18+
livvanРазработчик выдвинул внезапное решение использовать "вручную" сделанный в vba-коде индекс, вместо имеющегося автоматического, мотивируя это тем, что если из базы с автоматически сформированными индексами нужно будет удалить данные, потребуется её переносить или изменять структуру, то связи буду разрушены. 1. Я не вижу, каким образом в одной и той же БД с одними и теми же данными удаление разрушит либо не разрушит базу в зависимости от способа заполнения поля. Бред какой-то. 2. В нормальной БД данные не удаляются. Максимум - переносятся в архив. 3. И изменение структуры тоже нигде и никогда связей не разрушает. Вывод - разработчик хотя бы школу-то окончил? livvanНасколько я понял, по мнению "разработчика", автоматически генерированные индексы будут заново заполнятся и при этом будут ломаться связи. Например: в таблице три записи с ID 1, 2 и 3. Теперь если удалить запись с ID 2, то запись 1 останется там же где была, а у записи 3 индекс смениться на 2. И сколько вы ему уже заплатили? П.С. Где вы таких находить-то ухитряетесь? КритикВ этом случае в таблицу просто добавляется поле "Ключ офиса". И все. Это утверждение отлично смотрелось бы в книге теоретика, никогда не опускавшегося до практики. Как тот филин - помните? - "я стратегией занимаюсь". На практике же это "и всё" означает как минимум составной ключ. Чего уже достаточно, чтобы с позором похоронить эту идею. Ключ офиса, конечно, внести не помешает. Но "добавляется поле" - худшее из возможных решений. Ну или близкое к худшему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2012, 01:22 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=37895288&tid=1541584]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
149ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 226ms |
| total: | 469ms |

| 0 / 0 |
