Так... У меня работает на Firebird 2.1...

Вот что возвращает:


Добавлено через 1 минуту и 17 секунд

Не хочу отвлекаться, т.к. уже устал, но я бы с удовольствием покритиковал (конструктивно) структуру, уже ставшей мне родной  , БД!

Добавлено через 4 минуты и 45 секунд
Или же вот такой результат:

Для вот такого запроса:

эх ... у меня на AD возвращает почему - то 1 результат (((
видно придется думать о смене СУБД, другого выхода увы не вижу.

Присоединённый файл ( Кол-во скачиваний: 4 )
 re.jpg 52,68 Kb

Так читабельнее:


Добавлено через 2 минуты и 19 секунд


А исходные данные такие же как и мне были переданы?

Я понимаю, что если бы ошибка была... Но одна строка в результате...

АААААААААААААААААААА!!!! УУУУУУУУУУУУУУУУУ!!! Счастья наступило!!!
Чэл, огромное те спасибо!
Работает! =)

Нужно разобраться до конца  !

Ура!

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

Это сообщение отредактировал(а) Gluttton - 18.10.2009, 01:16

Мог бы, поставил бы те плюс =)

Добавлено через 36 секунд


так а что ещё осталось ... вроде ж работает? )

  

Пожайлуста  ...

Это не главное   , главное, что задача решена  ...

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

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



Это сообщение отредактировал(а) lat - 18.10.2009, 02:58

Поспешил с выводами. Задачка решена на 50%, продолжаем дальше мозго-штурм господа.

Когда цены одинаковые для одинаковых товаров, то выводит дубликаты. 

ЗЫ повторил эту ситуацию все в том же файле Tovar.sql. Есть 10 записей,  должно вывести 5 (кол-во оригинальных товаров, без дубликатов и с мин. ценой) после запроса. А выводит больше 5-ти, то есть кроме всего остального также показывает товар с одинаковой ценой но с разным источником (прайсом). Так что вот так =)



Это сообщение отредактировал(а) lat - 18.10.2009, 03:00

А по какому критерию определять запись поподающую в выборку при одинаковой цене?

Я так пологаю, что правильно было бы в тех случаях, когда цена минимальна в обоих прайсах выводить в графе с прайсами оба прайса (производить конкатенацию строк). Это можно реализовать рекурсивным запросом. Не все СУБД поддерживают рекурсивные запросы, но вот Firebird например поддерживает.
Вот тут и тут несколько примеров.
Firebird бесплатен и имеет embedded версию (т.е. для запуска сервера не обязательно производить установку его установку на ПК конечного пользователя, а достаточно "носить" в одной папке с программой несколько dll-ек). Я это к тому, что если реализация проекта не зашла далеко, то возможно стоит подумать о смене СУБД... Кроме Firebird существуют ещё и MySQL PosgreSQL а так же экспресс версии Oracle, MS SQL Server и многое другое например такое как SQLite...

Ещё раз хочу обратить внимание на то что испльзуемая структура БД неверна! Детально почитать об этом можно спросив у Googl'а про такое: "анамалия вставки", "аномалия удаления", "аномалия обновления". На пальцах приведу примеры недостатков...
1. БД не может хранить информацию о товаре, который отсутствует во всех прайсах.
2. Если характеристики товара изменились, то для обновления информации о товаре необходимо внести изменения во все строках, где он упоминается, а не в одном единственном месте.

А должно быть примерно так:
(ещё раз напомню, что это классическая реализация связи "многие ко многим")
Таблица "Товары" в которой описываются все товары, каждый товар упоминается один раз. Тут можно указать марку, производителя, основные характеристикие.
Таблица "Продавец" в которой описываются все продавцы (будь то фирмы, будь то частные лица или же интернет ресурсы). Тут можно хранить информацию о продавцах.
И "третья" связующая таблица "Товары_у_Продавца" (или же просто "Прайс" или ещё как нибудь назвать) в которой храняться как минимум (это обязательно) внешние ключи как на Товары так и на Продавцев. Так же можно хранить здесь информацию, которая характерна для данного образца Товара у конкретного Продавца это может быть и цена и гарантийный срок и ещё что нибудь...

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


Это сообщение отредактировал(а) Gluttton - 18.10.2009, 15:42

Ниче не понял)))



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

1. БД и не должна хранить инфу о товаре, который отсутствует  во всех прайсах. Потому что такого быть не может. Программа собирает инфу с прайсов, и не откуда более. И источник у товара всегда будет.  Это первое.
2. Каждый раз при анализе новых/старых прайсов вся инфа сбрасывается. БД очищается. То есть ничего обновлять не нужно. При каждом анализе происходит новое заполнение. И сама БД, в этом случае, это лишь кэш-буфер который неплохо справляется с поиском похожих товаров и "конкатенацией" этих товаров по минимальной цене)))

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

ЗЫ знаю что звучит как-то не так. Но поверьте, по соотношение потраченное_время/качество эта схема вполне приемлема. 



Это сообщение отредактировал(а) lat - 18.10.2009, 21:00

Да я и не против  ...


Когда дядя Петя идет на рынок ему тетя Сара говорит: "... купи самой дешёвой картошки". Дядя Петя приходит и видит, что по самой дешевой цене картошка продается в трех точках, тогда он звонит по мобильному тете Саре и спрашивает, какую именно выбрать, а тётя Сара ему говорит: "... из всех картошек по самой дешевой цене купи самую крупную, а если и крупная будет в нескольких точках, то купи ту до которой ближе идти  ".

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

Прикольно ты про Петю )))
Мне понравилось, вот если бы так все рассказывали, лаконично и понятно!)))



Я тоже не считаю это ошибкой.

Результаты будут сохраняться в файле, который будет потом передаваться на сайт роботу (не железному, а php ному =). Так вот робот просто не поймет почему ему дали два и более товара с одинаковыми характеристиками (робот не будет знать о источнике товара, только название - цена).

Так что не имеет значения какой из одинаковых товаров попадет в выборку, у них нет приоритета (по крайней мере в данной версии ПО такого не планирую ;)
Ну или " ... то купи ту до которой ближе идти" )))))



Это сообщение отредактировал(а) lat - 18.10.2009, 21:43

Самый простой способ реализовать выбор только одного товара - использовать ключевое слово DISTINCT. Использование SELECT DISTINCT позволяет отображать только разные записи. Т.е. для таблицы:

Запрос:

Вернёт:

А запрос:

Вернёт:

Но в то же время запрос:

Вернёт:

Я это всё к чему... У нас получается, что у двух товаров все данные одинаковые, кроме имени файла и первичного ключа...
Но т.к.

То решение лежит на поверхности:
1. Отказываемся от выбора поля с именем файла и с кодом товара.
2. Добавляем в запрос ключевое слово DISTINCT.

Опробировал на своей БД - работает...
Вот такой результат:

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

Это сообщение отредактировал(а) Gluttton - 18.10.2009, 22:37

угу. пущай начнутся танцы =)

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

Добавлено через 10 минут и 9 секунд
1 файл я создаю для робота
2 файл для себя (в нем полная инфа о товарах, в том числе и источник)
так что distinct тут не поможет (