Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Обсуждение identity и ...
|
|||
|---|---|---|---|
|
#18+
Мое руководство дает мне указание о том что бы не использовал автоинкремент. Оно хочет иметь процедуру, которая генерирует новое ID самостоятельно. Пожалуйста Ваши мнения. Вот мое: последний встасленный ID можно знать всегда. Да и вообще функций для этого навалом, дак зачем тогда ID самому генерить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2001, 01:06 |
|
||
|
Обсуждение identity и ...
|
|||
|---|---|---|---|
|
#18+
А чем руководство аргументирует свое указание? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2001, 01:59 |
|
||
|
Обсуждение identity и ...
|
|||
|---|---|---|---|
|
#18+
Оно у меня наполовину просто не доверяет автоинкременту, говоря о том что если его использовать, то обязательно где-нибудь столкнешся с проблемами по этому поводу. Другая половина это то что exe файл для БД уже написан и его надо будет переделать, если автоикремент использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2001, 02:48 |
|
||
|
Обсуждение identity и ...
|
|||
|---|---|---|---|
|
#18+
Проблем с счетчиками в MSSQL 7/2K нет. Но существуют и полноценные способы обходится без них. Посмотри http://www.osp.ru/win2000/sql/2001/04/865.htm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2001, 03:58 |
|
||
|
Обсуждение identity и ...
|
|||
|---|---|---|---|
|
#18+
Если речь идет об использовании автоинкремента для SQL-сервера, то все-таки лучше использовать именно штатные средства. Самопальные средства (без дырок в нумерации) не гарантируют того, что один и тот же идентификационный код не будет в разное время присвоен совершенно разным объектам. Ссылка на старый объект может наложиться на ссылку на новый и нарушить логическую целостность. Эта проблема, в принципе при аккуратном программировании обходится. Но вот когда несколько пользователей ОДНОВРЕМЕННО пытаются добавить запись в одну и ту же таблицу, то самопальные алгоритмы должны для корректной работы блокировать таблицу. Штатные средства ориентированы на генерацию корректных уникальных не конфликтующих идентификаторов без блокировки таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2001, 10:47 |
|
||
|
Обсуждение identity и ...
|
|||
|---|---|---|---|
|
#18+
1.Не обязательно блокировке таблицы. 2.ROLLBACK после mass update не будет приводить к потере большого кол-ва идентификаторов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2001, 20:35 |
|
||
|
Обсуждение identity и ...
|
|||
|---|---|---|---|
|
#18+
IMHO - один из главных недостатков автоинкремента в том что его значение не известно до момента сохранения записи. В ситуации когда мы имеем мастер-детайл набор данных с кешированием изменений - иногда возможно проще иметь другой способ генерации уникальных идентификаторов - например простенькую хранимую процедуру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2001, 06:43 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32011835&tid=1825866]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
27ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
| others: | 252ms |
| total: | 373ms |

| 0 / 0 |
