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

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

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

Скажите мастера можно ли такое реализовать? И если да то как? [D6, Oracle8]

Relaxxx © (2003-08-30 12:12:00)

У меня вот такая проблема. Есть поле в котором через запятую записаны номера заказов которые относятся к счету. Так вот, мне нужно зделать фильтрацию, например выбрать все счета где встречается заказ 111. Суть понятна? Вообще как реализовать эту фильтрацию?

hCat (2003-10-03 18:17:00) [1]

> a_andru (30.08.03 12:44) [1]
> where name_pole like ("%111%")

Все таки, наверное ;)
where name_pole like ("%,111,%")

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

Zacho (2003-09-18 21:09:00) [2]

> MsGuns © (18.09.03 20:56) [13]
> А если нет ? Т.е. это просто тонкая
> ссылка на некоторые толстые обстоятельства ?

Да даже если кроме номеров заказов в БД больше ничего по заказам не содержиться, то все равно при структуре, как у автора вопроса, могут возникнуть все возможные для ненормализованной (даже не в 1НФ !) таблицы аномалии.
Эх, жалко Дейта под рукой нет, а то какую-нибудь цитату бы привел :-)
Впрочем, все зависит от того, что именно с этими номерами заказов надо делать. Может, исходя из условий его задачи, это поле вполне можно считать атомарным.

MsGuns (2003-09-18 20:56:00) [3]

>Zacho © (18.09.03 20:49) [12]

Если заказы существуют в модели БД как объекты, т.е. есть соотв. таблицы, содержащие по ним инфу и т.д., тогда спору нет и я двумя руками за. А если нет ? Т.е. это просто тонкая ссылка на некоторые толстые обстоятельства ?

Zacho (2003-09-18 20:49:00) [4]

> MsGuns © (31.08.03 18:10) [9]

> MsGuns © (18.09.03 20:39) [11]

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

MsGuns (2003-09-18 20:39:00) [5]

>Krey (18.09.03 19:56) [10]
>Да но в данном случае по этому полю идет отбор. Соответственно база спроектирована неправильно

Неверно. В смысле неверно считать все, по чему может делаться поиск, собственно сущностью БД (если допустить, что любое поле БД является сущностью). Опять же простой пример:
В БД фармацевтической фирмы есть справочник объектов "препараты" (аналог товаров) и требуется возможность хранения некоторой произвольной дополнительной информации о препарате (нужна для продавцов - не провизоров), в частности о режиме приема препарата или перечне заболеваний, при которых противопоказан. Да и много чего еще может быть в подобном "примечании" - на все "атомы" не заложишь. Ессно, для этих целей предусмотрен VARCHAR(4095) или вообще текстовый BLOB. Туда тетенька - спец заносит все дополнительную инфу, нужную другим тетенькам - не спецам, чтобы не травануть доверчивую бабульку - покупательницу.
Вот и надо бывает продавцу выбрать, к примеру, обезболивающий препарат (есть такой признак-атом в БД), который имеет, к примеру, пояснение: "... не имеет противопоказаний" и "..против зубной боли.."

Krey (2003-09-18 19:56:00) [6]

MsGuns >> которая может фиксироваться или не фиксироваться

Да но в данном случае по этому полю идет отбор. Соответственно база спроектирована неправильно

MsGuns (2003-08-31 18:10:00) [7]

>Zacho © (30.08.03 12:49) [2]
>> Relaxxx © (30.08.03 12:12)
>Неправильно спроектирована БД. Прямое нарушение 1НФ - поле явно не атомарно. Лучше всего - перепроектировать базу.

При всем уважении не согласен. Бывают ситуации, когда не смысла выводить каждый термин (в узерском понимании) в отдельное поле БД. Пример ? Доверенность к накладной. Там указываются данные паспорта и ФИО, а также иногда доп. информация, которая может фиксироваться или не фиксироваться. Например, № авто, № путевого, вес груза и т.д. - всего не предусмотришь. То же самое можно сказать по справочник контрагентов, раздел "информация о телефонах и ФИО администрации".

В таких случаях отводят под всю эту дребедень однополе VARCHAR(1024), но в контролах его изображают мемо-подобно (в смысле с переносами строк и отступами - как ввел узер). Вот в таких случаях есть необходимость делать поиски по подобию.

VID (2003-08-30 14:43:00) [8]

я в общем не знаю, как там дела у oracle но у yaffil (клон IB) проблем с LIKE нету: в тбд ~4500 записей, запрос строится по LIKE - ставнению по НЕСКОЛЬКИМ (где то 4-5) полям, и невидать никаких тормозов.
Думается всё таки что и для Oracle, великого и ужасного, это тоже не будет проблемой :)

Zacho (2003-08-30 13:58:00) [9]

> Relaxxx © (30.08.03 12:57) [6]

Проверь - узнаешь.

Relaxxx (2003-08-30 12:57:00) [10]

реально ли использовать like если в таблице будет максимум 3000 строк, или при таком размере таблицы нужна все таки другая структура

Anatoly Podgoretsky (2003-08-30 12:53:00) [11]

Сильно, но если надо быстро, то нужна другая структура базы

Relaxxx (2003-08-30 12:52:00) [12]

а скажите, используя like скорость сильно уменьшится?

Anatoly Podgoretsky (2003-08-30 12:50:00) [13]

И 1112

Zacho (2003-08-30 12:49:00) [14]

> Relaxxx © (30.08.03 12:12)

Неправильно спроектирована БД. Прямое нарушение 1НФ - поле явно не атомарно. Лучше всего - перепроектировать базу.

a_andru (2003-08-30 12:44:00) [15]

where name_pole like ("%111%")
пишешь это в запросе. Результат должен вернуть строки где встречаються 111

Наверх

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