Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

ado и access

Страницы: < 1 2 3 4 >
Тимофей Ю. © (2011-06-23 14:05:00)
Всем привет, есть база на access. Выбрана потому что в ОС встроен драйвер и за собой можно таскать всего один файл базы.
Подключаюсь по адо, все бы хорошо, но в access нет фиксированного порядка строк. Для клиента обязательно чтобы можно было менять местами записи в таблице.
Структура таблицы:
id(autoinc) | value(text)

Без запросов тут не обойтись полагаю, профи подскажите как реализовать перемещение записей в таблице. Нужно всего две кнопки - вверх, вниз.

Anatoly Podgoretsky (2011-06-30 14:31:00) [21]
> Кщд (30.06.2011 12:43:35) [35]

На все конечно не сможет, BLOB поля не могут входить в состав первичного
ключа или индекса, а так пожалуйста, аедь и работа в гриде без первичного
ключа опирается на значения всех полей.

Кщд (2011-06-30 13:43:00) [22]
>Ega23 © (30.06.11 13:40) [40]
просто можете ответить, как ключ(PK, UQ) связан с 1НФ?
или как просто уникальный идентификатор(безо всяких ключей) связан с 1НФ?

Ega23 (2011-06-30 13:40:00) [23]

> коли речь о FB, то там есть ограничение на длину PK.
> так что - не аргумент.

И чо? А в том же MSSQL - ограничение в 4 Кб на длину одной записи в таблице.
Это уже конкретная реализация конкретной СУБД. Общая теория не запрещает тебе это сделать.

Кщд (2011-06-30 13:27:00) [24]
>sniknik © (30.06.11 12:54) [37]
>а тебе приводили пример когда идентификатора нет, никакого.
ничего подобного
напомню:

> SQLEXPRESS (23.06.11 16:32) [12]
>К тому же, считаю, что таблица без ключа
> - инвалид.

> Кщд (29.06.11 19:08) [21]
> аргументируйте?

>Ega23 © (30.06.11 07:57) [23]
>Первая нормальная форма.

>неспособен представить ничего кроме своего частного случая?

>Кщд (30.06.11 12:43) [35]
>вовсе не исключаю необходимости почистить записи, напр., в >середине лога.

>Ega23 © (30.06.11 12:56) [38]
прошу прощения, не понял исходного сообщения - помстилось, что речь идёт о нескольких PK на одной таблице))

коли речь о FB, то там есть ограничение на длину PK.
напр., что будет в результате:
CREATE TABLE TTT ( FLD1 varchar(32765) NOT NULL, FLD2 varchar(32765) NOT NULL, FLD3 varchar(32765) NOT NULL ); ALTER TABLE TTT ADD CONSTRAINT PK_TTT PRIMARY KEY (FLD1, FLD2, FLD3);

так что - не аргумент.

Ega23 (2011-06-30 12:56:00) [25]

> можно по-простому, для дурачков ответить на вопрос: какова
> связь между 1НФ и ключом

Дай определение ключа. Я не понимаю, что ты имеешь ввиду.

> какая БД это позволяет? просто интересно.

Под рукой сейчас только FireBird, пожалуйста:
CREATE TABLE TTT ( FLD1 INTEGER NOT NULL, FLD2 INTEGER NOT NULL, FLD3 INTEGER NOT NULL ); ALTER TABLE TTT ADD CONSTRAINT PK_TTT PRIMARY KEY (FLD1, FLD2, FLD3);

sniknik (2011-06-30 12:54:00) [26]
> либо отсекается "хвост" по дате.
вот она у тебя и выполняет роль идентификатора, неполноценного (все таки возможны случаи когда на одной "висит" несколько, но если непринципиально то пофиг), не индексированного (значит отбор всегда перебором, , но если редко то пофиг), а тебе приводили пример когда идентификатора нет, никакого.

неспособен представить ничего кроме своего частного случая? вот кому надо бы адресовать Игорь Шевченко © (30.06.11 11:36) [29]

> в MS SQL можно удалить дубликаты без ключа?
можно. чуток сложнее чем с ключом.

Кщд (2011-06-30 12:44:00) [27]
>Ega23 © (30.06.11 12:01) [34]
>В MSSQL тоже можно, я уже приводил пример.
>И чо?
в MS SQL можно удалить дубликаты без ключа?

Кщд (2011-06-30 12:43:00) [28]
>Ega23 © (30.06.11 11:52) [32]
>Тебе ключ, как "primary key", или как уникальная сущность?
можно по-простому, для дурачков ответить на вопрос: какова связь между 1НФ и ключом(суррогатным ли, естественным ли - не важно). На мой взгляд, это сравнение мокрого с зеленым. 1НФ утверждает наличие ключа? нет. Ключ в таблице гарантирует выполнение требований 1НФ? нет.
так в чем аргумент?

>Так я на все столбцы таблицы primary key наложить могу, в чём проблема-то?
какая БД это позволяет? просто интересно.

>sniknik © (30.06.11 11:54) [33]
>возьми да напиши пару запросов на удаление лишних с такой записью и без >(поймешь "в чем аргумент").
во-первых, не сталкивался с необходимостью удалять произвольные записи из лога - либо чистится весь, либо отсекается "хвост" по дате. вовсе не исключаю необходимости почистить записи, напр., в середине лога.
просто объясните, причем здесь нормальные формы?

Ega23 (2011-06-30 12:01:00) [29]

> запись физически вставленная позже может иметь ID меньший,
> чем у записи вставленной ранее

В MSSQL тоже можно, я уже приводил пример.
И чо?

sniknik (2011-06-30 11:54:00) [30]
> запись физически вставленная позже может иметь ID меньший, чем у записи вставленной ранее
и что это меняет в плане адресации, в примере, для выбора и "оставления" двух (первой/последней) из кучи одинаковых?

возьми да напиши пару запросов на удаление лишних с такой записью и без (поймешь "в чем аргумент"). только не нужно приводить пример/доказывать возможность для сервера поддерживающих и дающих доступ к внутреннему идентификатору... я в курсе по такие. а не понимаешь (если не докапываешься) вроде как ты.

Ega23 (2011-06-30 11:52:00) [31]

> какая связь между 1НФ и ключом?

Тебе ключ, как "primary key", или как уникальная сущность? Так я на все столбцы таблицы primary key наложить могу, в чём проблема-то?
Или ты ведёшь речь о суррогатном identity-ключе? Ну в большинстве моих таблиц он присутствует, да. Но бывает, что и нет.

sniknik (2011-06-30 11:47:00) [32]
> это надо везде.
я не говорил что нужно везде, я привел пример, в ответ на вопрос, где это может быть полезно.
если кто то видит в сказанном то, чего нет, это не проблема говорящего, это проблема восприятия слушающего.

Кщд (2011-06-30 11:46:00) [33]
>sniknik © (30.06.11 10:00) [26]
>автоинкрементный id-ключ помогут сделать это без проблем
напр., в Oracle нет автоинкремента
запись физически вставленная позже может иметь ID меньший, чем у записи вставленной ранее

>Ega23 © (30.06.11 09:48) [25]
>Но раз ты так хочешь докопаться,
не хочу "докопаться" - просто не понял, в чем аргумент
какая связь между 1НФ и ключом?

>то приведи пример, где таблица не удовлетворяет 1НФ. И сделано это >осознанно.
мы, например, активно используем в качестве типов полей пользовательские типы(Oracle, create type), т.о. в поле может храниться и объект и список объектов и таблица.

Игорь Шевченко (2011-06-30 11:36:00) [34]
sniknik © (30.06.11 10:51) [28]

таблица логов таблице логов люпус эст. А ты берешься судить конкретный случай, и радостно говоришь - ага, а мне тут так надо, значит, это надо везде.

sniknik (2011-06-30 10:51:00) [35]
не, избыточно, это вот когда к примеру - есть у меня инфо-таблица где указана версия базы/приложения/время апдейта/время загрузки данных/... в общем всего 8 полей, и гарантировано и всегда должна быть только 1 строка (смысла нет тут историю вести, это оперативные данные, историю тех же апдейтов как раз в логах можно посмотреть)...
вот тут ключ/авто инкремент избыточно, а в таблице в которой в теории, и с не нулевой долей вероятности возможно понадобится адресация к одной записи... (ну вот хотя бы показать лог в разбивке по чему то) это предусмотрительно...

Игорь Шевченко (2011-06-30 10:42:00) [36]
sniknik © (30.06.11 10:00) [26]

> полезно?

Избыточно

Впрочем, у танцоров всегда найдется, чему помешать

sniknik (2011-06-30 10:00:00) [37]
> ... чем полезен ID?
> напр., таблица логов?
приходишь с отпуска и видишь лог забит однотипными, и совершенно одинаковыми ошибками типа "сервер не доступен", или еще лучше "обновление времени завершилось ошибкой, время установлено в 0" (чтобы дата не взяла на себя "роль ключа", не отвлекала внимание)...
чешешь репу и думаешь, а нафига мне такое счастье разглядывать одну бесполезную запись, и выискивать среди нее другие значимые. думаешь дайка оставлю только первую и последнюю обозначив "период сбоя"... автоинкрементный id-ключ помогут сделать это без проблем. полезно?

Ega23 (2011-06-30 09:48:00) [38]

> т.е. наличие в БД хотя бы одной таблицы, не удовлетворяющей
> минимум 1НФ, говорит об ошибках проектирования? в этом аргумент
> или?...

Я ничего не имею против осознанной и разумной денормализации.
Но раз ты так хочешь докопаться, то приведи пример, где таблица не удовлетворяет 1НФ. И сделано это осознанно.

Кщд (2011-06-30 09:13:00) [39]
Anatoly Podgoretsky © (29.06.11 19:29) [22]
>Кому то придется взять на себя роль ключа
с целью?
напр., таблица связи многие ко многим - чем полезен ID?
напр., таблица логов?

>Ega23 © (30.06.11 07:57) [23]
>Первая нормальная форма.
т.е. наличие в БД хотя бы одной таблицы, не удовлетворяющей минимум 1НФ, говорит об ошибках проектирования? в этом аргумент или?...

Ega23 (2011-06-30 07:57:00) [40]

> Кщд (29.06.11 19:08) [21]
>
> >SQLEXPRESS (23.06.11 16:32) [12]
> >К тому же, считаю, что таблица без ключа - инвалид.
> аргументируйте?

Первая нормальная форма.

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »