ado и access

← →
Тимофей Ю. (2011-06-23 14:05) [0]

Всем привет, есть база на access. Выбрана потому что в ОС встроен драйвер и за собой можно таскать всего один файл базы.
Подключаюсь по адо, все бы хорошо, но в access нет фиксированного порядка строк. Для клиента обязательно чтобы можно было менять местами записи в таблице.
Структура таблицы:
id(autoinc) | value(text)

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

← →
Ega23 © (2011-06-23 14:19) [1]

create table ttt ( id int identity (1,1) not null, value varchar(...), orderField int not null default 0 ) select * from ttt order by orderField udpate ttt set orderField = x where id = ...

← →
Тимофей Ю. (2011-06-23 15:22) [2]

id | value | orderField
1 | sdfsd | ??
2 | sdf sd |
3 | hjfg
4 | asd
5 | nbvn
6 | qwe
7 | hjf

спасибо, Ega23, мне не понятно что должно быть в поле orderField, если также числа по номерации, то какой смысл в этом столбце если можно использовать для этого столбец id ? А если мне нужно переместить 6 запись на месте 2, при этом все записи начиная с 2 сдвинуться вверх

← →
sniknik © (2011-06-23 15:53) [3]

> если можно использовать для этого столбец id ?
потому что его нельзя использовать... для этого.
+ а еще лучше ему поставить PRIMARY KEY и использовать как искусственный ключ... по назначению.

← →
SQLEXPRESS (2011-06-23 15:53) [4]

>> какой смысл в этом столбце если можно использовать для этого столбец id ?
можно. но нельзя.

id дается раз и навсегда, по нему на эту строку могут ссылаться другие строки
а если при каждой сортировке менять id, будет разброд и шатание и адъ с израелем

← →
Ega23 © (2011-06-23 16:00) [5]

> мне не понятно что должно быть в поле orderField, если
> также числа по номерации, то какой смысл в этом столбце
> если можно использовать для этого столбец id ? А если мне
> нужно переместить 6 запись на месте 2, при этом все записи
> начиная с 2 сдвинуться вверх

Смотри. У тебя есть уникальный идентификатор ID, первичный ключ. В моём примере он int, но может быть что угодно (составной по нескольким полям, GIUD или ещё что-то).
У тебя есть поле orderField, которое строго int. И вот выборку ты сортируешь уже по нему.
Лично я предпочитаю отдать это поле на "откуп" пользователю. Т.е. когда он редактирует конкретную запись в таблице, он сам задаёт это значение. Чем меньше - тем "выше" в выборке будет запись (или чем больше, тогда добавить order by orderField desc)

можно сделать в "автоматическом режиме". Например, у тебя в таблице 9 записей:1 "a" 1 2 "б" 3 3 "в" 5 4 "г" 7 5 "д" 9 6 "е" 2 7 "ж" 4 8 "з" 6 9 "и" 8

Делаем select * from ttt order by orderField

получаем
1 "a" 1 6 "е" 2 2 "б" 3 7 "ж" 4 3 "в" 5 8 "з" 6 4 "г" 7 9 "и" 8 5 "д" 9

Допустим, ты хочешь поменять местами вторую и пятую запись в данной выборке. Т.е. "е" и "в"
Тогда:
1. Запоминаем id и orderField для е. Это 6 и 2
2. Запоминаем id и orderField для в. Это 3 и 5
3. Update ttt set orderField = 5 where id = 6
4. Update ttt set orderField = 2 where id = 3

снова выбираем:
select * from ttt order by orderField
получаем
1 "a" 1 3 "в" 2 2 "б" 3 7 "ж" 4 5 "е" 5 8 "з" 6 4 "г" 7 9 "и" 8 5 "д" 9

← →
sniknik © (2011-06-23 16:01) [6]

> id дается раз и навсегда
автоинкремент это не ключ... просто их часто совмещают, но это не значит что они равны...

> по нему на эту строку могут ссылаться другие строки
это ключ
и он вполне может быть "естественным", а автоиинкремент рядом для других целей.

← →
SQLEXPRESS (2011-06-23 16:02) [7]

← →
SQLEXPRESS (2011-06-23 16:04) [8]

sniknik © (23.06.11 16:01) [6]
согласен.
Но.. а для чего ты это сказал? :)

← →
Ega23 © (2011-06-23 16:06) [9]

> Ega23 © (23.06.11 16:00) [5]

Опечатка. В последней выборке будет

снова выбираем:
select * from ttt order by orderField
получаем

1 "a" 1 3 "в" 2 2 "б" 3 7 "ж" 4 6 "е" 5 8 "з" 6 4 "г" 7 9 "и" 8 5 "д" 9

← →
Ega23 © (2011-06-23 16:14) [10]

Да, и ещё: если не хотим повторяющихся значений в orderField (хотя почему бы и нет?), то при вставке новой записи ставим orderField = select IsNull(Max(orderField) + 1, 1)

← →
sniknik © (2011-06-23 16:23) [11]

> Но.. а для чего ты это сказал? :)
автоинкремент не раз и навсегда, от него ничего не поплывет, это ты говорил про ключ... а в примере выше, на вопрос от которого ты отвечал, просто автоинкремент...

например есть табличка где раз в 3 месяца автоинкременты с 0 пускают... просто людям так проще, сказать - "15796" запись, чем значение гуида (ключа) выговорить, особенно по телефону, а разбирают только сегодня/вчера.

← →
SQLEXPRESS (2011-06-23 16:32) [12]

[11]
ну да, есть такое дело

а как еще можно понять в таблице наименование поля id, к тому же оно number. К тому же, считаю, что таблица без ключа - инвалид.

Кстати с гайдами, имхо и работает медленнее, и есть вероятность пересечения, вроде бы, если репликации из многих БД в одну идут.

← →
Ega23 © (2011-06-23 16:33) [13]

> автоинкремент не раз и навсегда

Ну и эта.. Не знаю, как в Access, но в MSSQL:

USE AdventureWorks2008R2; GO -- Create tool table. CREATE TABLE dbo.Tool( ID INT IDENTITY NOT NULL PRIMARY KEY, Name VARCHAR(40) NOT NULL ) GO -- Inserting values into products table. INSERT INTO dbo.Tool(Name) VALUES ("Screwdriver") INSERT INTO dbo.Tool(Name) VALUES ("Hammer") INSERT INTO dbo.Tool(Name) VALUES ("Saw") INSERT INTO dbo.Tool(Name) VALUES ("Shovel") GO -- Create a gap in the identity values. DELETE dbo.Tool WHERE Name = "Saw" GO SELECT * FROM dbo.Tool GO -- Try to insert an explicit ID value of 3; -- should return a warning. INSERT INTO dbo.Tool (ID, Name) VALUES (3, "Garden shovel") GO -- SET IDENTITY_INSERT to ON. SET IDENTITY_INSERT dbo.Tool ON GO -- Try to insert an explicit ID value of 3. INSERT INTO dbo.Tool (ID, Name) VALUES (3, "Garden shovel") GO SELECT * FROM dbo.Tool GO -- Drop products table. DROP TABLE dbo.Tool GO

http://msdn.microsoft.com/ru-ru/library/ms188059.aspx

← →
Ega23 © (2011-06-23 16:35) [14]

> Кстати с гайдами, имхо и работает медленнее, и есть вероятность
> пересечения, вроде бы, если репликации из многих БД в одну
> идут.

Совпадения в принципе возможны, но крайне маловероятны.
Но никто не мешает тебе сделать составной ключ, по GUID и Identity

← →
SQLEXPRESS (2011-06-23 16:45) [15]

по гайду перестал вообще делать
однажды попробовав схему ID_DEPARTMENT + Identity, считаю ее оптимальной

или последовательности, например четные/нечетные
(когда в одной БД с 1 начинается, а в другой с 2, и шаг у обоих 2)

ну или +10. т.е. все id заканчивающиеся на 1 - из одной БД. на 2 - из другой,
на 9 из девятой

← →
Ega23 © (2011-06-23 17:34) [16]

> SQLEXPRESS (23.06.11 16:45) [15]

Это от задачи зависит. Мы как-то для сливки баз с разных объектов для записи использовали bigint, где старший int - id базы, младший - id записи

← →
Сергей М. © (2011-06-24 15:02) [17]

> в access нет фиксированного порядка строк. Для клиента обязательно
> чтобы можно было менять местами записи в таблице

Ты не поверишь - не найдется, пожалуй, ни одной мало-мальски приличной СУБД, которая выкрутасничала бы с "менять местами записи в таблице" в угоду ничем не обоснованным сиюминутным капризам.

← →
MsGuns © (2011-06-29 14:13) [18]

Похоже, каприз рожден привычкой работать "как в экселе".
Диагноз: полная аптутация :)

← →
Игорь Шевченко © (2011-06-29 14:38) [19]

> К тому же, считаю, что таблица без ключа - инвалид.

опыт дело наживное

← →
Кщд (2011-06-29 19:06) [20]

>SQLEXPRESS (23.06.11 16:45) [15]

>или последовательности, например четные/нечетные
>ну или +10. т.е. все id заканчивающиеся на 1 - из одной БД. на 2 - из другой
плохие, немасштабируемые решения

← →
Кщд (2011-06-29 19:08) [21]

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

← →
Anatoly Podgoretsky © (2011-06-29 19:29) [22]

Как идентифицировать запись? Кому то придется взять на себя роль ключа, а некоторые вещи без ключа вообще не сделать.

← →
Ega23 © (2011-06-30 07:57) [23]

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

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

← →
Кщд (2011-06-30 09:13) [24]

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

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

← →
Ega23 © (2011-06-30 09:48) [25]

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

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

← →
sniknik © (2011-06-30 10:00) [26]

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

← →
Игорь Шевченко © (2011-06-30 10:42) [27]

sniknik © (30.06.11 10:00) [26]

> полезно?

Избыточно

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

← →
sniknik © (2011-06-30 10:51) [28]

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

← →
Игорь Шевченко © (2011-06-30 11:36) [29]

sniknik © (30.06.11 10:51) [28]

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

← →
Кщд (2011-06-30 11:46) [30]

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

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

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

← →
sniknik © (2011-06-30 11:47) [31]

> это надо везде.
я не говорил что нужно везде, я привел пример, в ответ на вопрос, где это может быть полезно.
если кто то видит в сказанном то, чего нет, это не проблема говорящего, это проблема восприятия слушающего.

← →
Ega23 © (2011-06-30 11:52) [32]

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

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

← →
sniknik © (2011-06-30 11:54) [33]

> запись физически вставленная позже может иметь ID меньший, чем у записи вставленной ранее
и что это меняет в плане адресации, в примере, для выбора и "оставления" двух (первой/последней) из кучи одинаковых?

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

← →
Ega23 © (2011-06-30 12:01) [34]

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

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

← →
Кщд (2011-06-30 12:43) [35]

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

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

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

← →
Кщд (2011-06-30 12:44) [36]

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

← →
sniknik © (2011-06-30 12:54) [37]

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

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

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

← →
Ega23 © (2011-06-30 12:56) [38]

> можно по-простому, для дурачков ответить на вопрос: какова
> связь между 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);

← →
Кщд (2011-06-30 13:27) [39]

>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 13:40) [40]

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

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

← →
Кщд (2011-06-30 13:43) [41]

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

← →
Anatoly Podgoretsky © (2011-06-30 14:31) [42]

> Кщд (30.06.2011 12:43:35) [35]

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

← →
Anatoly Podgoretsky © (2011-06-30 14:33) [43]

> Кщд (30.06.2011 13:27:39) [39]

Первичный ключ по определению только один, если два, то какой то вторичный.

> Ega23 (30.06.2011 13:40:40) [40]

8 кб, ну и что, у других или больше или меньше.

> Кщд (30.06.2011 13:43:41) [41]

Конечно никак, 1НФ говорит всего лишь об атомарности

> просто можете ответить, как ключ(PK, UQ) связан с 1НФ?

Сначала определение ключа (PK, UQ) в студию.

> Конечно никак, 1НФ говорит всего лишь об атомарности

А что, наличие ПК в таблице не является признаком атомарности записи?

> 8 кб, ну и что, у других или больше или меньше.

Раньше 4 было, сейчас уже не в курсе.
В сферической теории в вакууме никаких ограничений нет и быть не может. И вобщем-то правильно.
В практической реализации же таких ограничений - дофига и больше.

← →
Кщд (2011-06-30 14:50) [49]

>Ega23 © (30.06.11 14:41) [46]
не смешно

>Ega23 © (30.06.11 14:45) [48]
дело в том, что Вы не понимаете, что такое 1НФ
ключи непричем

>Anatoly Podgoretsky © (30.06.11 14:39) [45]
о чем и речь

> не смешно

А я и не смеюсь, я на полном серьёзе.
У меня складывается впечатление, что мы на разных языках говорим. Вот я и прошу о согласованности определений.

Ega23 © (30.06.11 14:45) [48]

> В практической реализации же таких ограничений - дофига
> и больше.

Назови пожалуйста практическую реализацию более или менее широко используемую СУБД, в которой невозможно создать таблицу без первичного или уникального ключа. Подумай, почему так.

в догонку к [51] для буквоедов - под первичным или уникальным ключем понимается CONSTRAINT соответствующего вида или ему подобная клауза.

> Назови пожалуйста практическую реализацию более или менее
> широко используемую СУБД, в которой невозможно создать таблицу
> без первичного или уникального ключа. Подумай, почему так.

Дык в любой возможно. Конкретно ПК как constraint может и не быть. Это не очень хорошо в плане индексирования, а также заставляет брать на себя ответственность за уникальность данных. Но пуркуа бы и не па?
Собственно, я уже вторую страницу об этом долдоню.

> Ega23 (30.06.2011 14:43:47) [47]

Не является, 1НФ относится ко всем полям сразу

> Ega23 (30.06.2011 14:45:48) [48]

Когда, 15 лет назаl, в MS SQL 6.5?

> Игорь Шевченко (30.06.2011 15:07:52) [52]

Можно и без этой кляузы, а прямо в определение поля.

> Когда, 15 лет назаl, в MS SQL 6.5?

В 7.2 точно. В 2000 - вроде тоже. 4046 байт, ЕМНИП.

> Не является, 1НФ относится ко всем полям сразу

create table ttt ( id int identity (1,1) not null, data image null, constraint pk_ttt primary key (id) );

> Ega23 (30.06.2011 15:57:57) [57]

C 2000 я работал - 8К

> C 2000 я работал - 8К

Я спорить сейчас не буду, ибо давно дело было. Вполне возможно, что ограничение на 4К было в семёрке, под ней года 3 работали.
Хотя я толком не представляю себе, какая должна быть таблица, чтобы лимит в 4К на запись выбрать, если учесть, что varchar, varbinary, nvarchar, image, text и ntext по сути - указатели.

Не указатели, а реальные данные, кроме image, text и ntext - эти передаются через потоки, но опять же не указатели, указатели вообще бессмысленно передавать между приложениями, тем более между машинами,

> Не указатели, а реальные данные,

Для char - реальные. Для varchar - указатель на кучу, где эти данные размещены.

для рекордсета "между приложениями, тем более между машинами" не может быть кучи, только реальные данные, и исключения "блоб-оподобное" которые через потоки, при обращениях, но тоже реальные после чтения.

ado и access Найти похожие ветки