White OwlА я еще вот с этим не согласен:
1.
2.
3.
4.
5.
*** GOOD code: ***
DO WHILE TRUE
ll_row = dw.GetNextModified(ll_row, Primary!)
IF li_row < 1 THEN EXIT
{code fragment}
LOOP
С классической точки зрения такой цикл надо описывать так:
1.
2.
3.
4.
5.
DO
ll_row = dw.GetNextModified(ll_row, Primary!)
IF ll_row >= 1 THEN
{code fragment}
END IF
LOOP WHILE ll_row = 0
Я тоже так думал, начитавшись книжек в колледже. Но МНЕ удобней так, как я описАл - жизнь научила. Если {code fragment} сам по себе имеет инденты (табы), зачем усугублять? Если ты привык за годы карьеры иначе и не имеешь охоты "переключаться" - дык и не надо! Привычка - страшная сила, по себе знаю.
White OwlПро создание первичных ключей. Ты перечислил несколько минусов натуральных ключей (все эти минусы можно отмести одним общим возражением - неправильно определено что является натуральным ключом).Приведённое определение - не моё, и звучит очень просто: натуральный ключ - это такой первичный ключ (или кандидат), значения которого кроме уникальной идентификации записей таблицы имеют какой бы то ни было дополнительный смысл в реальной жизни.
White OwlНо ты ни слова не сказал о минусах сурогатных ключей. А вот лично я их ненавижу. Да, они удобнее натуральных в случае если натуральный ключ надо поменять, но зато клиенту прийдется повозится чтобы создать этот самый сурогатный ключ. Хорошо если в БД есть встроенная система генерации (типа sequences в Oracle или @@identity в Sybase). А если нету? Как ты собираешься создавать номер для ключа в мультиклиентском приложении?Даже в тех субэдэшках, что имеют внутренние средства генерации ключей, лучше ими не пользоваться (и в большинстве проектов, куда меня засылала партия, они и не использовались). Решение простое: имеется таблица, состоящая из двух полей: entity_name и next_value. Создал в системе новую сущность - загоняешь в таблицу запись для неё:
INSERT INTO tbl_ids (entity_name, next_value) VALUES ('emp_id', 1 );
И создаёшь хранимую процедуру или функцию которая принимает название сущности и возвращает следующее значение нумератора (доступ скриптов к таблице будет осуществляться ТОЛЬКО через неё); естественно, эта функция увеличивает next_value на единицу готовя почву для следующего вызова; даже более того - если запись для данной сущности ещё не существует, она её создаёт вышеназванным инсёртом (или генерирует ошибку, что, ИМХО, лучше - всё надо делать обдуманно). Этот способ (в отличие от неуправляемых оракловских сиквенсов) делает генерацию ключа частью транзакции (со всеми вытекающими для мультиклиентских приложений преимуществами). Да и зачем загружать систему кучей сиквенсов если можно иметь одну маленькую табличку? А сначала создавать запись с отоинкрементом, затем считывать новорожденное значение через @@identity - всё равно что ехать из Питера в Москву через Северный Полюс. Лучше разбить всё на этапы: сначала генерируешь нумератор в переменную, затем вставляешь везде, где надо в рамках данной транзакции (например, в первичный ключ таблицы-master и во внешние ключи таблиц-details). Именно так я собираеюсь создавать номер для ключа в мультиклиентском приложении. Лишь одно обидно: все эти умные идеи - не мои :-).
White OwlНатуральные ключи всегда лучше.В программировании (да и вообще в жинзи) вряд-ли есть вещи, которые ВСЕГДА лучше.
White OwlДаже если ты вынужден передавать пять-восемь полей для идентификации одной записи - все равно это намного лучше чем работать с абстрактным числом.А если 20-30 - это, по твоей логике, вааще кайф! Кстати, натуральный номер работника - такое-же абстрактное число (плюс куча всяких ограничений и возможных неприятных сюрпризов в будущем), просто оно уже существовало до создания записи в базе данных. Что будешь с этим делать, ненавистник суррогатных ключей?
White OwlХотя бы тем, что серверу БД прийдется вести только один индекс а не два. А это приводит к более быстрой работе всей базы.Зависит от многих обстоятельств. В некоторых ты прав (например, если до черта инсёртов и мало селектов). А кроме этого момента, ЧЕМ ИМЕННО естественные ключи лучше? Ты просто написал что ненавидишь суррогатные, что, согласись, не аргумент. Я не ищу спора - мне просто совершенно откровенно интересно что хорошего в том, что за все эти годы выпило у меня столько крови.
White OwlПро передачу параметров в окна.
А зачем вообще открывать окна с параметрами? Намного проще делать так:
1.
2.
Open(w_target)
w_target.of_SetKey('somekey', 'value')
w_target.of_SetKey('otherkey', 'othervalue')
Тогда ты сохранишь и читабельность кода и не понадобится заводить структур, и у тебя останется возможность открыть окно с неполным набором параметров. И в будущем, если понадобится добавить в w_target новый параметр, тебе не нужно будет заниматься перекомпиляцией всех объектов которые открывают данное окно (и используют структуру для передачи параметров)Речь шла вообще о передаче параметров между объектами, окно - просто пример. В твоём примере с of_SetKey есть преимущества, но есть и недостатки. Представь, что w_target открываетска из многих скриптов w_source-а - каждый раз писАть набор вызовов of_SetKey, да ещё и в будущем мейнтененс предоставлять? Да и зависит w_target от w_source-а, что не есть хорошо - я бы предпочёл принять аргументы, проверить (если требуется) и рапихать куда надо внутри w_target-а (скажем, в функции, вызываемой фреймворком из события Open).
