|
|
|
| Здравствуйте!
У меня есть, предположим, 3 таблицы и в каждой из них есть поле owner. Правильно ли я делаю выборку? -
SELECT table1.id as a, table2.id as b, table3.id as c FROM table1,table2,table3 WHERE owner = '1234567'
И второй вопрос:
На страницы использую AJAX чтоб он мне из базы без перезагрузки вывел все предметы которые начинаются на выбранную букву. Все работает, только вместо русских букв он выводит квадратики и т.д. (не знаки вопроса). Подключаюсь к базе как указано в книге "Самоучитель по PHP" (include файла в котором уже есть запрос на SET NAMES) | |
|
|
|
|
|
|
|
для: stas1987
(04.07.2007 в 21:54)
| | Нет, вы должны обязательно указать какой таблице принадлежит поле owner, тем более если оно присуствует в трёх таблицах сразу. | |
|
|
|
|
|
|
|
для: stas1987
(04.07.2007 в 21:54)
| | Неправильно.
Таблицы должны быть связаны, а не просто перемножены через запятую.
Ели кто не в курсе до сих пор - запятая в списке FROM - операция декартового произведения таблиц, а не просто закорючка.
Учиться настраивать кодировки и писать многотабличные запросы нужно безо всякого AJAX. Задолго до его изучения. | |
|
|
|
|
|
|
|
для: Trianon
(05.07.2007 в 10:19)
| | Trianon, я же вполне ясно выразился, что мне нужно, чтобы подсказали. Если тебе станет легче, то я могу извиниться за такой дерзкий и выходящий за все правила морали вопрос насчет запросов и кодировок. Но не мог бы ты подсказать как мне выйти из этой ситуации? | |
|
|
|
|
|
|
|
для: stas1987
(05.07.2007 в 19:36)
| | как минимум покзать структуру таблиц, и описать, какой результат Вы ждете от запроса.
У меня впечатление , что Вы неясно зачем, пытаетесь одним запросом выдернуть данные из трех таблиц, никак не связанных между собой логически.
Почему Вы не хотите сделать это тремя запросами? | |
|
|
|
|
|
|
|
для: Trianon
(05.07.2007 в 22:01)
| | Мне просто нужно вывести по все строки из этих трех таблиц, которые принадлежат тому или иному владельцу (например, в трех таблицах- типы товара, и мне нужно вывести какие из этих трех типов товара он, скажем, не оплатил).
Т.е. вы считаете, что лучше сделать три запроса и каждый из них выводить в цикле. Спасибо за направление! | |
|
|
|
|
|
|
|
для: stas1987
(07.07.2007 в 00:55)
| | >Т.е. вы считаете, что лучше сделать три запроса
>и каждый из них выводить в цикле.
Если не исправлять структуру БД - да. Именно так.
Но сперва я бы подумал, нельзя ли все товары запихнуть в одну таблицу.
Или если не получается запихнуть товары целиком - уложить в нее хотя бы общие свойства этих самых товаров.
Вот тогда можно будет обойтись одним запросом.
Но это - совершенно однозначно - крохи достигнутого.
Самое главное - в результате этого перестанут возникать проблемы на ровном месте, в процессе работы с общей массой товаров. Писать запросы станет проще простого.
А уж из общей таблицы получить срез товаров определенного вида - сложности никакой. Одно условие в разделе WHERE - и от таблицы осталась нужная треть.
>Спасибо за направление!
Теперь - пожалуйста. | |
|
|
|
|
|
|
|
для: stas1987
(04.07.2007 в 21:54)
| | Только пару дней назад была похожая проблема не помню где, но нашёл решение, структура таблиц может быть вообще разной но главное чтобы поле которые надо выбрать присутствовало во всех таблицах....В данном случае если три таблицы....
(SELECT table1.id FROM table1 WHERE table1.owner = '1234567')
UNION
(SELECT table2.id FROM table2 WHERE table2.owner = '1234567')
UNION
(SELECT table3.id FROM table3 WHERE table3.owner = '1234567')
Как видно запрос плох если число таблиц огромно....У меня было 101 таблица и куча условий а также связи, но что ни странно работает да к тому же довольно шустро...... | |
|
|
|
|
|
|
|
для: Борис
(07.07.2007 в 03:01)
| | >структура таблиц может быть вообще разной но главное чтобы
Главное - для чего? Или для кого?
Для меня - при формировании схемы БД - главное, чтобы с базой было легко работать.
Создавать запросы, расширять функциональность, ввносить требуемые сущности.
>Как видно запрос плох если число таблиц огромно....У меня было 101 таблица и куча условий а также связи, но что ни странно работает да к тому же довольно шустро......
Это смотря с чем сравнивать.
Самокат обычно ездит быстрее асфальтового катка. Тем не менее я предпочту либо велосипед, либо автомобиль. | |
|
|
|
|
|
|
|
для: Борис
(07.07.2007 в 03:01)
| | В данном случае, например мне, пришлось пожертвовать правильной структурой т.к каждая таблица представляет собой определённый подраздел объявлений, подраздел в своё время может иметь неограниченное к-во дополнительных полей, определяющих дополнительные параметры(для продвинутого поиска по параметрам). Тоесть шаблон полей не id, zagolovok, name, city, date для всех категорий. А примерно так id, info, zagolovok, city marka, model', KW, motor, kuzov, ....(и так до бесконечности) для к примеру автомобилей и id, info, zagolovok, city, sostojanie, etaz, metr2, komnatq, udobstva, .....(и так до бесконечности) в зависимости от того сколько параметров добавлено к каждой категории. Также я пожертвовал нормализацией, т.к. выборка объявлений по всем имеющимся категориям происходит только в крайних случаях(т.к. не каждому человеку захочется просмотреть в моём примере все объявления со всех категорий и происходит это очень-очень редко, когда происходит текстовой поиск по заданному слову в поле "искать текст", да и то для этого случая думаю создать так сказать дополнительную общую таблицу где будут поля id(main_cat_id, sub_cat_id, string) где string уже преобразованная строка всех параметров объявления(Продам audi a8 3,7 169 kw седан автоматическая коробка передач.........) . Приоритет - когда имя таблицы уже имеется, тоесть категория уже выбрана, и человек уже работает именно с той таблицей, которая содержит объявления только выбранной категории. Помоему если бы у меня была отдельная общая таблица для всех, мои приоритеты бы не выполнялись, т.е. когда посетитель захотел бы просмотреть раздел автомобили. Ему бы прешлось перелопатить всю таблицу, где помимо объявлений об автомобилях есть ещё другая 101 категория....А если записей в каждой из них примерно по 10 000 тысяч(образно)? Или я не правильно что-то понял.... | |
|
|
|
|
|
|
|
для: Борис
(07.07.2007 в 15:53)
| | >Также я пожертвовал нормализацией
Вот ключевая фраза.
Жертвовать нормализацией (если Вы не суперпрофессионал БД-разработчик) нельзя.
А если можно - то только очень осторожно - так чтобы при этом минимально страдала гибкость.
В частности общие поля объявлений вполне можно было вынести в одну таблицу, на чей первичный ключ сослаться чужими ключами из таблиц подкатегорий, если уж Вам так хотелоь работать с отдельными таблицами. Ссылка на первичный ключ - мгновенна. | |
|
|
|
|
|
|
|
для: Trianon
(07.07.2007 в 17:40)
| | Дело в том, что я бы с радостью объединил все типы объявлений(авто, мото, запчасти, комплектующие и т.д.) в одну таблицу, но все дело в том, что в разделе авто около 100000 записей, запчастей и комлектующих еще больше.
Или вы считаете, что рационально будет все объединить в одну? | |
|
|
|
|
|
|
|
для: stas1987
(07.07.2007 в 23:17)
| | За какой период времени?
Если из них активно используется только 10% , таблицу лучше распилить по горизонтали, а не по вертикали. На активку и архив.
Ну и наконец, 100 тысяц - это не так много...
А по вертикали - распилить можно тоже, но не так, как у Вас.
А на столбцы, которые используются часто, и которые редко. | |
|
|
|