-
Правильный$Вася (25.03.10 18:17) [40]
> Игорь Шевченко © (25.03.10 14:01) [38]
потому что кроме гипотетической экономии памяти никаких плюсов больше нет
да и в сторону мы уходим, это уже десятки раз перетирали и каждый остался при своем
я предпочитаю суррогатные первичные ключи, а то, что может претендовать на натуральный первичный ключ, просто делаю уником
гораздо гибче во многих случаях - можно и на то опереться, и на это, зависит от логики конкртной задачи
и даже если вдруг окажется, что натуральный ключ уже не совсем ключ, ничего не развалится, в отличие от противников суррогата -
Anatoly Podgoretsky © (25.03.10 19:59) [41]> Медвежонок Пятачок (25.03.2010 10:06:34) [34]
Да никакие изменения первичного ключа не являются проблемой. Надо чтобы форма редактирования/вставки возвращала правильный номер. Это еще один плюс в пользу редактирования в отдельной форме. -
Anatoly Podgoretsky © (25.03.10 20:00) [42]> MsGuns (25.03.2010 14:34:39) [39]
Не приводит, если использовать cascade updates, а я не вижу причины не использовать их -
Anatoly Podgoretsky © (25.03.10 20:01) [43]> Правильный$Вася (25.03.2010 18:17:40) [40]
И у тебя получается дублирование -
Игорь Шевченко © (25.03.10 20:11) [44]Правильный$Вася (25.03.10 18:17) [40]
> я предпочитаю суррогатные первичные ключи, а то, что может
> претендовать на натуральный первичный ключ, просто делаю
> уником
Джо Целко зовет таких IDиотами :)
Я не совсем понимаю - если нет referential ссылки на таблицу с естественным ключом из N полей, зачем вводить дополнительную сущность ?
Телега хорошо едет с четырьмя колесами. -
Правильный$Вася (25.03.10 20:29) [45]
> Я не совсем понимаю - если нет referential ссылки на таблицу
> с естественным ключом из N полей, зачем вводить дополнительную
> сущность ?
у меня практически всегда есть (98%), так что не вижу смысла ради 2% делать исключение из своего правила
> Anatoly Podgoretsky © (25.03.10 20:01) [43]
> > Правильный$Вася (25.03.2010 18:17:40) [40]И у тебя получается
> дублирование
лучше продублировать 1 поле GUID, чем ссылаться на 10 полей из многих разных таблиц
экономия памяти, нервов и времени огромная -
Anatoly Podgoretsky © (26.03.10 07:36) [46]> Правильный$Вася (25.03.2010 20:29:45) [45]
Откуда взялось 10 полей? В связи как правило участвует одно поле. -
>Anatoly Podgoretsky © (26.03.10 07:36) [46]
>Откуда взялось 10 полей? В связи как правило участвует одно поле.
Каждый "этаж" - одно поле. 10-этажный "небоскреб" - 10 полей в "пентхаузе" :) -
Правильный$Вася (26.03.10 11:13) [48]
> Откуда взялось 10 полей? В связи как правило участвует одно поле.
если PK составной, то в связи не может быть его часть, верно ведь? -
evvcom © (26.03.10 14:34) [49]1. Как уже было сказано в [2] "Вноси данные через датасет - ничего рефрешить не надо."
2. Я копал внутренности букмарка одаковского датасета, это не что иное как номер строки датасета, поэтому добавляя новую запись (через грид или отдельную форму), вызывая метод Add, мы добавляем запись в конец набора, а после рефреша и order by в запросе эта запись становится уже далеко не последней (чаще всего).
3. Я немного модифицировал одаковский датасет, написав наследника, добавив туда KeyFieldName, и написал одну регулярную процедуру. После этого просто вызаваю DSRefresh(ADataSet):procedure DSRefresh(DS: TDataSet; KeepPos: Boolean);
var
l_Values : array of Variant;
l_FieldCount: Integer;
l_FieldNames: string;
l_FieldName : string;
l_RecNo : Integer;
l_RecCount : Integer;
begin
if (DS is TOraStoredProc) and (TOraStoredProc(DS).StoredProcName <> '')
then begin
if DS.Active and (DS is TMyOraStoredProc) and
(TMyOraStoredProc(DS).KeyFieldName <> '')
then begin
l_FieldNames := TMyOraStoredProc(DS).KeyFieldName;
l_FieldCount := 0;
l_RecNo := 1;
while True do begin
l_FieldName := ExtractFieldName(l_FieldNames, l_RecNo);
if l_FieldName <> '' then begin
Inc(l_FieldCount);
SetLength(l_Values, l_FieldCount);
l_Values[l_FieldCount - 1] := DS.FieldValues[l_FieldName];
end
else
Break;
end;
DS.Close;
DS.Open;
if DS.Active then
DS.Locate(l_FieldNames, l_Values, []);
end
else begin
l_RecNo := DS.RecNo;
DS.Close;
DS.Open;
l_RecCount := DS.RecordCount;
if KeepPos and (l_RecCount > 0) then begin
if l_RecNo > l_RecCount then
l_RecNo := l_RecCount;
if DS.Active then
DS.MoveBy(l_RecNo - 1);
end;
end;
end;
end;
Противники RecNo могут поменять их на букмарки, но в хелпе явно написано, что букмарк после переоткрытия датасета становится невалидным! Это в общем случае. Таким образом, данная процедура отлично у меня работает уже несколько лет и с одним ключом, и с составным, и даже пытается работать, если я где-то забыл указать ключ.
Но следует понимать, что этот рефреш написан не для рефреша после изменений, т.к. см. пункт 1-й, а для работы после изменений значений входных параметров!