Фильтр для получения списка значений.

← →
-=Le][=- © (2007-11-08 17:02) [0]

У меня локальная база данных, хранится в файле XML и загружаю её в ClientDataSet. В базе есть поле в которое заношу имена пользователей. Какой фильтр наложить чтобы получить список пользователей?
Тоесть чтобы каждое имя юзера встречалось только раз в этом списке!

← →
Reindeer Moss Eater © (2007-11-08 17:07) [1]

Фильтром клиентдатасета этого не сделать.
Только если его агрегатными полями.

← →
sniknik © (2007-11-08 17:16) [2]

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

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

← →
Reindeer Moss Eater © (2007-11-08 17:19) [3]

и кстати если имена у тебя повторяются то таблице требуется нормализация и деление на 2

Вообще-то замена строковых имен идентификаторами клиентов никакого отношения к нормализации не имеет.
Ну ни малейшего.

:)

← →
Reindeer Moss Eater © (2007-11-08 17:21) [4]

Лично я бы выбрал XPath"ом список имен и уже с ним бы работал, убирая дубликаты.

← →
-=Le][=- (2007-11-08 17:23) [5]

sniknik ©
Это справедливо для больших баз, а у меня маленькая прога с маленькой базой!
Две связанные таблицы которые хранятся в двух XML-файлах!
Раньше все было в текстовом формате в ini-файле и занимало от 2 до 5 КБ!

← →
sniknik © (2007-11-08 17:23) [6]

а то что мы этим самым убираем дублирующиеся значения? просвети темного.

← →
sniknik © (2007-11-08 17:25) [7]

> Это справедливо для больших баз
какая разница? хоть из одной таблицы, термины не меняются, в базе таблицы, в таблицах поля.

← →
Reindeer Moss Eater © (2007-11-08 17:26) [8]

Дублировались строки.
Ввели таблицу клиентов, стали дублироваться идентификаторы.

Ни до ни после никакая нормальная форма не была нарушена.

← →
Johnmen © (2007-11-08 17:28) [9]

> Reindeer Moss Eater © (08.11.07 17:19) [3]
> Вообще-то замена строковых имен
> идентификаторами клиентов никакого отношения к нормализации
> не имеет.Ну ни малейшего.

Это ты погорячился...

← →
Reindeer Moss Eater © (2007-11-08 17:30) [10]

таблица из трех полей:

Заказ №1 1000р Петя Иванов Заказ №2 100р Иван Петров Заказ №3 99р Петя Иванов

Какая именно из первых пяти нормальных форм нарушена?
И какая нормальная форма появляется, если это заменть на:
Заказ №1 1000р 1 Заказ №2 100р 2 Заказ №3 99р 1

← →
Johnmen © (2007-11-08 17:32) [11]

Нарушена третья форма.

← →
sniknik © (2007-11-08 17:36) [12]

> Ни до ни после никакая нормальная форма не была нарушена.
считай как хочеш.

> Какая именно из первых пяти нормальных форм нарушена?
хочеш поговорить? зачем? можно прочитать (минута поиска в гугле)
http://www.wwwmaster.ru/article.php?nart=21

← →
Reindeer Moss Eater © (2007-11-08 17:36) [13]

Если она и была нарушена (а это не так), то второй вариант никак не исправляет положения.

PK - номер заказа.

Все неключевые поля зависят только от PK
Ни одно неключевое поле не зависит от другого неключевого поля.
Все поля содержат атомарные значения.

← →
sniknik © (2007-11-08 17:47) [14]

о кстати, сдесь лучше (сначала дал ту ссылку что гугл выдал первой, эта четвертая)
http://www.softtime.ru/bookphp/gl12_6.php

в примере делается тоже самое что я и предложил, только там повторяются названия профессий.

← →
Reindeer Moss Eater © (2007-11-08 17:51) [15]

Если бы у меня было четвертое поле с адресом прописки заказчика, тогда да. Получаем поле, зависящее от ключа и от неключевого поля одновременно.

Причем по вашей логике если заменить строку адреса на его ид из справочника адресов, то к нам вроде бы должна вернуться третья нормальная форма. Но это же не так.

Потому что замена строки на число не имеет никакого отношения к нормализации.
Всего лишь меняется тип данных и появляется новой отношение один к одному и все.
Никакой доп. нормализации при этом не наступает.

← →
Johnmen © (2007-11-08 20:15) [16]

Меняется тип данных, создается еще одна таблица, появляется новое отношение один ко многим.

← →
Reindeer Moss Eater © (2007-11-08 21:28) [17]

Это очень бородатый оптический обман. Нормализации не добавилось не убавилось.

← →
sniknik © (2007-11-08 22:15) [18]

> Это очень бородатый оптический обман. Нормализации не добавилось не убавилось.
а ты читал по ссылке в [14], не смущает, что действия в учебнике называемые нормализацией имеют пример, просто один в один предлагаемому сдесь?

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

Johnmen © (08.11.07 20:15) [16]
игнорирование очевидного, обычно означает, что человек не желает пере-убеждаться (т.е. никакие слова не помогут).

p.s. а вообще после [12] первый абзац, и продолжать не стоило... лажанулся.

← →
Reindeer Moss Eater © (2007-11-08 23:14) [19]

И все таки это не нормализация, а простая замена типа данных ключа.
Мой "Вася Иванов" зависит только от первичного ключа целиком и не зависит от других полей, и ваш идентификатор Васи Иванова как искуственный ключ то же самое не зависит ни от чего кроме первичного ключа.

У меня 3НФ и у вас 3НФ
Ничего не изменилось кроме типа данных.

← →
Reindeer Moss Eater © (2007-11-08 23:18) [20]

цитата по ссылке:
Эта таблица избыточна - для каждого из сотрудников повторяются одинаковые названия профессий. Т.е. схема такой базы данных не нормализована.

>(учебник ламером писанный? так найди другой, тебе убедительный, там
ссылок предостаточно выдавало)

В точку. Именно ламером он и написан.

Третья нормальная форма - любой неключевой атрибут зависит целиком от всего первичного ключа и не зависит от других неключевых атрибутов.

← →
Reindeer Moss Eater © (2007-11-08 23:28) [21]

Пример структуры где есть действительно повторяющиеся группы данных, нарушающие первую нф:

create table customer( name varchar(..), phone1 varchar(...), phone2 varchar(...), phone3 varchar(...), address1 varchar(...), address2 varchar(...), address3 varchar(...), );

← →
Reindeer Moss Eater © (2007-11-08 23:34) [22]

Пример структуры, нарушающей 2НФ:

ID Отдела, (Pk)
ID Сотрудника, (Pk)
ID Начальника отдела

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

← →
Reindeer Moss Eater © (2007-11-09 00:04) [23]

Кстати выдержка с ресурса по первой ссылке:

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

Речь как раз и идет о предложенной вами обоими бесмыссленной (с точки зрения нормализации!) дробления одной таблицы на две

← →
-=Le][=- (2007-11-09 10:10) [24]

Смотрю на ваш разговор и удивляюсь! Причем здесь нормализация к фильтрации? Если я нормализую базу тогда все проблемы решатся? Я смогу наложить фильтр так чтобы получить список значений?

Зачем нормализация если она не приносит никакого выигрыша? Это всеравно что утверждать что моя машина не ездит потому что у нее руль справа, а не слева как у всех!

По тех ссылках что дал sniknik сказано:

>...
> Зачастую, чтобы извлечь информацию из нормализованной базы
> данных, приходится конструировать очень сложные запросы,
> которые к тому же, бывает, работают довольно медленно -
> из-за, главным образом, большого количества соединений
> таблиц. Поэтому, чтобы увеличить скорость выборки данных
> и упростить программирование запросов, нередко приходится
> идти на выборочную денормализацию базы.
>...
> Для небольшой базы данных это не критично, но в больших по
> объёму базах данных это скажется на размере базы и, в конечном
> счёте, на скорости доступа.
>...

Так что дискуссии об нормализации маленькой базы данных есть некорректными с позиции самой нормализации!
Может еще нормализовать таблицу в которой есть поля типа Boolean (BOOL)? А что? Значение повторяются! Значит нужно создать таблицу вида:
ID | Value 1 | 0 //False 2 | 1 //True
И связать все таблицы в которых есть поля соответственного типа с этой таблицей!

я тебе давно уже сказал, что фильтром клиентдатасета задачу не решить

uses MSXML2_TLB; var xdoc : IXMLDomDocument2; xlist : IXMLDomNodeList; begin ..... xlist := xdoc.SelectNodes("//ROW/@CLIENTNAME"); //далее создаем свой список, включаем в нем опцию игнорирования дубликатов и шуруем в цикле по списку xlist, добавляя имена в созданный список MyList.Add(xlist.item[i].NodeValue); end;

← →
-=Le][=- (2007-11-09 10:26) [27]

Reindeer Moss Eater
А может sniknik и знает как через клиентдатасет с нормализованной базой прийти к нужному результату! А если нет то база мертва и нормализация ее не спасет!

То, что предлагал сникник, позволит иметь xml в котором не повторяются имена клиентов, но это не имеет к нормализации никакого отношения.

таблица вида (ID, NAME) не добавляет нормализованности.

Я бы даже сказал, что структура вида (ID,NAME) с ключем ID может нарушать некоторые нормальные формы старше третьей.
так как NAME - это запросто может быть потенциальным первичным ключом.
А их быть не должно с точки зрения нормализации.

← →
-=Le][=- (2007-11-09 10:40) [30]

Reindeer Moss Eater
Согласен! Нам не о чем спорить!
Я просто хочу услышать от sniknik и Johnmen чем нормализация, если это можно так назвать, мне поможет!

Ну так сделай таблицу справочника клиентов и будет тебе счастье. И фильтра не понадобится.

> Может еще нормализовать таблицу в которой есть поля типа Boolean (BOOL)?
извращение идеи не есть сама идея... но! ->

> А что? Значение повторяются! Значит нужно создать таблицу вида:
> ...
можеш смеяться, но именно так и нужно поступить в случае если нужна независимость самого значения... т.е. если ты не знаеш какое там будет значение True или False (null), знаеш только что каким бы оно не было, сущность его будет одна для какойто группы записей в основной таблице.
реальный пример правда чтото не придумывается... попробуй понять абстрактно.

> Я просто хочу услышать от sniknik и Johnmen чем нормализация, если это можно так назвать, мне поможет!
в нормализованной базе у тебя попросту будет готовый справочник уникальных имен.
другое дело твоя, база, тут действительно нужны преобразования/обработка. например другой рекордсет в памяти, в который перекладывать из твоего в цикле только не внесенные уже значения имен.
или даже проще (не надо проверок), создаешь список, ставишь ему StringList.Duplicates:= dupIgnore; и просто перекладываешь в него в цикле из клиентского рекордсета свои имена.

> Ну так сделай таблицу справочника клиентов и будет тебе
> счастье. И фильтра не понадобится.

Это если клиенты являются объектами предметной области, т.е. их действительно кто-то регистрирует, они обладают рядом атрибутов помимо Name.
В противном случае, это именно текстовый атрибут сущности Заказ, более того, значение его недостоверно, если написано "Петя Иванов", то это не значит, что заказавший имеет какое-то отношение к какому либо Пете Иванову.

Фильтр для получения списка значений. Найти похожие ветки