Модификация через сетку табл. без ключей

← →
Juice © (2005-09-21 17:07) [0]

Не приходит в голову никаких решений: как модифицировать записи в таблице, в которой нет ни одного ключа ? Все ее поля можно изменять как угодно. Что ж получается, в where ничего не напишешь! Может вы что-то подскажите?
p.s. Таблицы такие не я проектировал :)

← →
}{ander © (2005-09-21 17:08) [1]

А слабо суррогатный первичный ключ сделать?

← →
Sergey13 © (2005-09-21 17:11) [2]

Интересно назначение такой таблицы.

← →
msguns © (2005-09-21 17:12) [3]

Гиблое дело искать черную кошку в темной комнате.
Таблица без ключей как улица без названия.

← →
Digitman © (2005-09-21 17:14) [4]

что-то ты какую-то околесицу несешь ..

что значит "как модифицировать записи" ? да обычно же ! UPDATE ..
причем здесь WHERE ? как писал ты этот clause, так и пиши его ! Ничего не изменилось ..

Другой вопрос, КАК предусмотреть подбор и последующую модификацию именно НУЖНЫХ записей, в пределах более чем одной из состава одинаковых по содержимому интересующих полей ... ты ЭТОТ вопрос хотел задать или где ?)

← →
ANB © (2005-09-21 17:16) [5]

На чем таблица ?

← →
Reindeer Moss Eater © (2005-09-21 17:20) [6]

UpdateMode := upWhereAll

← →
ANB © (2005-09-21 17:22) [7]

> Reindeer Moss Eater © (21.09.05 17:20) [6]
- даже в этом режиме можно нарваться на грабли, если есть дубли строк.

← →
Juice © (2005-09-21 17:25) [8]

> что значит "как модифицировать записи" ? да обычно же !
> UPDATE ..
> причем здесь WHERE ? как писал ты этот clause, так и пиши
> его ! Ничего не изменилось ..

Пример: таблица table, пусть всего из двух полей, пофиг каких, field1 и field2, юзер может в сетке редактировать оба поля. Приведите плз. пример ModifySQL.

> А слабо суррогатный первичный ключ сделать?

Я с аналогичным успехом могу и обычный первичный ключ сделать, что скорее всего и произойдет. Вопрос не по необходимости а чисто из интереса.
> На чем таблица ?

Firebird

← →
Feos (2005-09-21 17:25) [9]

Я бы написал запрос, а проблема с дублями неразрешима

← →
Reindeer Moss Eater © (2005-09-21 17:29) [10]

- даже в этом режиме можно нарваться на грабли, если есть дубли строк.

Никаких граблей.
Все заапдейтится в полном соответствии с where.

← →
Desdechado © (2005-09-21 19:04) [11]

> Пример: таблица table, пусть всего из двух полей, пофиг каких, field1 и field2, юзер может в сетке редактировать оба поля.
> Приведите плз. пример ModifySQL.
По старым значениям этих полей строим WHERE в команде UPDATE

← →
AlexWlad © (2005-09-21 21:03) [12]

1. проектировщику - по шапке (если возможно)
2. добавь свое поле и забей в него значения, потом сделай автоинкремент...

> Пример: таблица table, пусть всего из двух полей, пофиг каких, field1 и field2, юзер может в сетке редактировать оба поля.

пример к примеру :)
делаем подобную таблицу из 2х полей
CREATE TABLE Table1 (Field1 Int, Field2 Int)
заполняем однородными данными несколько записей (чтобы невозможно было идентифицировать запись по значению полей...)
INSERT INTO TABLE1 (FIELD1,FIELD2) VALUES (1,1)
выполнить запрос пару раз хотябы (чтобы 2 записи одинаковых минимум было).
теперь подключаем таблицу к "сетке" и редактируем в ней одно поле (Field1 первой записи меняем на 2, к примеру), при вызове Post (записи в базу) в этом случае что по твоему произойдет (должно)? смена значения одного поля? (как будто бы логичное)

нет, произойдет ошибка "обновление влияет на слишком большое количество записей" и смена значений всех записей в столбце Field1. вернее в зависимости от компонент доступа ошибку будет не у всех, но записи поменяют все. потому как они общаются с SQL серверами посредством запросов (даже TxxxTable...) а запрос (условие) на одну запись, меняли значение то только в одной, не по чему строить, значения всех одинаковы...

вообщето для файребирда (и еще некоторых серверов) можно запрос на обновление одной записи и в этом случае построить, там есть чтото вроде "номера записи" (rdb$db_key, в других другие), но стандартные компоненты врядли его используют, а используют то им же и хуже, нет гарантий что в процессе работы его значение в базе не изменится.... (потом начнется песня про "станные" ошибки сервера ...;) "всегда работает, а в пятницу тринадцатого валится. чудо!!!" (а то админ базы "сборку мусора" "запускает" в любимый день ;), или что другое вроде бы независящее)

Я вот немного подумал и пришел к следующим мыслям:

1. В соответствии с реляционной моделью все кортежи в переменной-отношении (т.е. все записи в таблице) должны быть уникальными. Т.е. наличие таблицы с одинаковыми строками противоречит реляционной модели. Если проанализировать это с точки зрения здравого смысла, то столкнемся с вопросом: а зачем, собственно, в таблице 123274 совершенно одинаковые строки? Прихоит только один ответ:

2. Сбор информации, которая накапливается со временем. В этом случае, глядя на структуру таблицы, можно придумать только один вид запроса к такой таблице, который будет иметь смысл (с некоторыми вариациями):
select field1, field2, count(*) from table group by 1,2

т.е. мы определяем количество кортежей определенного вида. Но в этом случае лучше ввести в таблицу еще одно поле field3, создать первичный ключ по полям field1, field2 (во-первых, чтобы исключить повторение записей, во-вторых для однозначной идентификации записи) и хранить в поле field3 количество записей такого вида.

3. Последнее: наличие проблем обновления - признак того, что нужно заняться нормализацией.

PK я подабавлял около 17:15 :) Интересовало что-то наподобие :

> вообщето для файребирда (и еще некоторых серверов) можно
> запрос на обновление одной записи и в этом случае построить,
> там есть чтото вроде "номера записи" (rdb$db_key, в других
> другие), но стандартные компоненты врядли его используют,
> а используют то им же и хуже, нет гарантий что в процессе
> работы его значение в базе не изменится.... (потом начнется
> песня про "станные" ошибки сервера ...;) "всегда работает,
> а в пятницу тринадцатого валится. чудо!!!" (а то админ
> базы "сборку мусора" "запускает" в любимый день ;), или
> что другое вроде бы независящее)

> Интересовало что-то наподобие

че за база-то? Или я это где-то пропустил?

>> Интересовало что-то наподобие :
А что в данном совете то не устраивает?
rdb$db_key - уникальный номер записи, генерируемый сервером.

> А что в данном совете то не устраивает?
> rdb$db_key - уникальный номер записи, генерируемый сервером.
>

Совет заключается в том, чтобы не использовать этот совет, однако этот совет и есть ответ на мой вопрос.

Модификация через сетку табл. без ключей Найти похожие ветки