|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Тема: DataGridView Среда Visual Basic STUDIO’2010 Professional При добавлении новой строки в DataGridView Запись с таким ключём уже имеется. Как обработать эту ситуацию при добавлении В таблицу новой записи? Спасибо. Код: vbnet 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2013, 13:47 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Код: plaintext
Код: plaintext
Vova_1805Как обработать эту ситуацию при добавлении В таблицу новой записи? Код: sql 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2013, 14:05 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Только это C#, а не Visual Basic Код: c# 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2013, 14:15 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
автоинкремент используется в том случае, когда ключём служит поле данных типа СЧЁТЧИК, который в моей ситуации НЕРАЗУМНО ПРИМЕНЯТЬ. В моеё ситуации ключём служит ИДЕНТИФИКВЦИОННЫЙ КОД, выдаваемый налоговой инспекцией, а он УНИКАЛЬНЫЙ ДЛЯ КАЖДОГО ГРАЖДАНИНА. Вот почему при вводе надо проверять. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2013, 14:25 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
как применить приведенный Вами текст к VB.NET STUDIO'2010 авторif not exists (select 1 from table where id = @id) insert into table -- необязательная часть else update table set ... where id = @id ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2013, 14:27 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Vova_1805как применить приведенный Вами текст к VB.NET STUDIO'2010 авторif not exists (select 1 from table where id = @id) insert into table -- необязательная часть else update table set ... where id = @idЭто TSQL, если будете через процедуру менять записи в таблице ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2013, 14:55 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Vova_1805УНИКАЛЬНЫЙ ДЛЯ КАЖДОГО ГРАЖДАНИНА Не уникальный. Я переезжал с Питера в Москву, и в местной налоговой разбирался, почему на меня было открыто сразу 3 ИНН. Оказалось, что у меня был + не разбираясь сразу две госструктуры оформили мне новые. Кажется, какая-то заморочка была, что при регистрации в новом регионе старый ИНН теряет силу, и выписывается новый. Так что предусматривайте ситуацию в программе, когда у человека может меняться ИНН. Возможно, номер пенсионного удостоверения будет лучшим выбором? Если говорить о моем выборе - я сторонник суррогатных ключей. И в данном случае выбрал бы автогенерацию GUID. Всякие ИНН и прочие натуральные ключи - доп поле + индекс на нем. Vova_1805Вот почему при вводе надо проверять Проверка осуществляется по достаточно простому алгоритму, который доступен и для дошкольников: поискать по ключу, и если не найдено - делать инсерт. Vova_1805как применить приведенный Вами текст Поскольку вы постеснялись указать, с какой СУБД вы работаете, я привел псевдокод а-ля T-SQL. В VB.NET я не рублю, поэтому приблизительный код для шарпа (хотя, как правильно заметили выше, ваш код и есть шарповый): Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2013, 15:26 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
забыл поле Identity указать в списке названий столбцов: Код: c# 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2013, 15:28 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Vova_1805поле данных типа СЧЁТЧИК, который в моей ситуации НЕРАЗУМНО ПРИМЕНЯТЬ. В моеё ситуации ключём служит ИДЕНТИФИКВЦИОННЫЙ КОД, выдаваемый налоговой инспекцией, а он УНИКАЛЬНЫЙ ДЛЯ КАЖДОГО ГРАЖДАНИНА. НЕРАЗУМНО ВЕРИТЬ, что этот код будет неизменен. Согласно п.3.1. Порядка и условий присвоения, применения, а также изменения идентификационного номера налогоплательщика при постановке на учет, снятии с учета юридических и физических лиц, утвержденных приказом МНС России от 03.03.2004 №БГ-3-09/178 (зарегистрирован в Минюсте России 24.03.2004 №5685) (далее – Порядок) присвоенный физическому лицу идентификационный номер налогоплательщика (ИНН) не подлежит изменению, за исключением случаев внесения изменений в нормативные правовые акты Российской Федерации либо изменения его структуры в связи с внесением изменений в положения раздела 1 Порядка. Vova_1805, Вы уверены, что изменения в нормативные акты невозможны? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2013, 18:55 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Arm79, авторсторонник суррогатных ключей. И в данном случае выбрал бы автогенерацию GUID. Более худшего решения для перфоманса придумать сложно. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2013, 08:42 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Ken@t, О чем речь? У него идет учет пользователей. Где вы видите там перфоманс? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2013, 10:20 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Arm79Ken@t, О чем речь? У него идет учет пользователей. Где вы видите там перфоманс? Вроде по русски написал же. Зы . у вас суррогатные PK с типом GUID - кластерные ? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2013, 10:29 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Ken@tВроде по русски написал же. Зы . у вас суррогатные PK с типом GUID - кластерные ? 1) Нет, не кластерные 2) Я пытаюсь вам сказать, что даже если бы и были кластерные, при учете пользователей это не принципиально, не такая там большая таблица. И особенность её такова, что большинство транзакций являются транзакциями на чтение ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2013, 10:43 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Arm79, 1 В том , что PK строки таблицы GUID нет ничего полохо или хорошего, но ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2013, 11:04 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
2. В таком случае PK должен быть не кластерным, в противном случае дефрагментация индекса при добавлении со всеми вытекающими. 3. Настоящий ключ вырождается в Unique . 4. Надо понимать, что будет кластерным индексом. 5. Надо понимать,что увеличение размерности строки. Вообще, GUID в качестве PK , скорее суррогатные ключи - чаще всего ошибки проектирования, на практике. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2013, 11:16 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Ken@tВ таком случае PK должен быть не кластерным, в противном случае дефрагментация индекса при добавлении со всеми вытекающими Может и кластерным, NEWSEQUENTIALID() Можно и по джобу перестраивать индексы, и так далее. Ken@tНастоящий ключ вырождается в Unique тут не понял, можно уточнить? Ken@tНадо понимать, что будет кластерным индексом я бы выбрал LastName (это же фамилия у ТС?) Ken@tНадо понимать,что увеличение размерности строки Какой строки? Какой размерности? если речь идет о UNIQUEIDENTIFIER, то там 16 байт всего Ken@tGUID в качестве PK , скорее суррогатные ключи - чаще всего ошибки проектирования, на практике Не всегда. GUID для репликационных вещей удобнее всего ИМХО. У ТС учет пользователей. Есть вероятность, что база будет распределенная. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2013, 11:28 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Код: plaintext 1. 2. 3.
Скрипт на табличных переменных Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
результаты: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Скрипт на временных таблицах Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54.
результаты: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
скрипт для кластерных индеков приводить не буду, он такой же, ниже результаты: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Вариант с NEWSEQUENTIALID оказался быстрее всех, сколько бы итераций теста не запускал. Остальные три варианта более менее близки друг другу. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2013, 14:58 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Arm79, А причём здесь оценка скростив вставки в БД ? Было же В таком случае PK должен быть не кластерным, в противном случае дефрагментация индекса при добавлении со всеми вытекающими Вот оно дефрагментация индекса и падение производительности при использовании GUID. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50.
Ещё раз - идентификатор строки может быть суррогатным GUID , но никогда не кластерным, вмести с этим натруальный ключ - становится уникальным ограничением, индексом . Остаётся определить требование к кластерному индексу или это куча будет. К репликации GUID то же с какого боку ? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2013, 09:08 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
И ещё Кластерный индекс . То есть для поля LastName которое не уникально произошло бы увеличение таблицы ещё на 16 байт. Перевед архитектору и DBA/ ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2013, 09:14 |
|
Запись с таким кдючём имеется
|
|||
---|---|---|---|
#18+
Ken@tЕщё раз - идентификатор строки может быть суррогатным GUID , но никогда не кластерным, вмести с этим натруальный ключ - становится уникальным ограничением, индексом . Остаётся определить требование к кластерному индексу или это куча будет. К репликации GUID то же с какого боку ? Это вы в общем, а обсуждаем мы таблицу ТС. Я утверждаю, что основное ограничение в использовании GUID в качестве суррогатного КЛАСТЕРНОГО ключа обходится использованием NEWSEQUENTIALID() вместо указанного вами NEWID() Далее, после вставки 100 тысяч элементов типа Пользователь по NEWID(), ествественно, индекс будет сильно фрагментированным. Но вы не учитываете специфику таблицы. Эта таблица будет редко пополняемой. То есть массовых вставок новых данных не будет. И необходимость перестроения индексов после первого раза будет редкой. Зачем далеко ходить, вот обсуждение GUID для репликации Ken@tИ ещё Кластерный индекс . То есть для поля LastName которое не уникально произошло бы увеличение таблицы ещё на 16 байт. Перевед архитектору и DBA/ У ТС нет натурального уникального ключа. Ни по одному из столбцов. Поэтому естественный выбор для кластерного индекса из представленного в наличии - это наиболее часто используемое поле. Я думаю, что это Фамилия. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2013, 11:26 |
|
|
start [/forum/topic.php?fid=20&msg=38110363&tid=1405352]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
58ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 165ms |
0 / 0 |