Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В. Социальная инженерия и социальные хакеры. Авторы: Кузнецов М.В., Симдянов И.В. PHP на примерах (2 издание). Авторы: Кузнецов М.В., Симдянов И.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. PHP. Практика создания Web-сайтов (второе издание). Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум MySQL

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Выборка из 3-х таблиц по общему полю и квадратики вместо букв
 
 автор: stas1987   (04.07.2007 в 21:54)   письмо автору
 
 

Здравствуйте!

У меня есть, предположим, 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)

   
 
 автор: cheops   (05.07.2007 в 09:14)   письмо автору
 
   для: stas1987   (04.07.2007 в 21:54)
 

Нет, вы должны обязательно указать какой таблице принадлежит поле owner, тем более если оно присуствует в трёх таблицах сразу.

   
 
 автор: Trianon   (05.07.2007 в 10:19)   письмо автору
 
   для: stas1987   (04.07.2007 в 21:54)
 

Неправильно.

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

Учиться настраивать кодировки и писать многотабличные запросы нужно безо всякого AJAX. Задолго до его изучения.

   
 
 автор: stas1987   (05.07.2007 в 19:36)   письмо автору
 
   для: Trianon   (05.07.2007 в 10:19)
 

Trianon, я же вполне ясно выразился, что мне нужно, чтобы подсказали. Если тебе станет легче, то я могу извиниться за такой дерзкий и выходящий за все правила морали вопрос насчет запросов и кодировок. Но не мог бы ты подсказать как мне выйти из этой ситуации?

   
 
 автор: Trianon   (05.07.2007 в 22:01)   письмо автору
 
   для: stas1987   (05.07.2007 в 19:36)
 

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

   
 
 автор: stas1987   (07.07.2007 в 00:55)   письмо автору
 
   для: Trianon   (05.07.2007 в 22:01)
 

Мне просто нужно вывести по все строки из этих трех таблиц, которые принадлежат тому или иному владельцу (например, в трех таблицах- типы товара, и мне нужно вывести какие из этих трех типов товара он, скажем, не оплатил).

Т.е. вы считаете, что лучше сделать три запроса и каждый из них выводить в цикле. Спасибо за направление!

   
 
 автор: Trianon   (07.07.2007 в 01:14)   письмо автору
 
   для: stas1987   (07.07.2007 в 00:55)
 

>Т.е. вы считаете, что лучше сделать три запроса
>и каждый из них выводить в цикле.

Если не исправлять структуру БД - да. Именно так.

Но сперва я бы подумал, нельзя ли все товары запихнуть в одну таблицу.
Или если не получается запихнуть товары целиком - уложить в нее хотя бы общие свойства этих самых товаров.

Вот тогда можно будет обойтись одним запросом.
Но это - совершенно однозначно - крохи достигнутого.
Самое главное - в результате этого перестанут возникать проблемы на ровном месте, в процессе работы с общей массой товаров. Писать запросы станет проще простого.
А уж из общей таблицы получить срез товаров определенного вида - сложности никакой. Одно условие в разделе WHERE - и от таблицы осталась нужная треть.

>Спасибо за направление!
Теперь - пожалуйста.

   
 
 автор: Борис   (07.07.2007 в 03:01)   письмо автору
 
   для: 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 таблица и куча условий а также связи, но что ни странно работает да к тому же довольно шустро......

   
 
 автор: Trianon   (07.07.2007 в 12:54)   письмо автору
 
   для: Борис   (07.07.2007 в 03:01)
 

>структура таблиц может быть вообще разной но главное чтобы

Главное - для чего? Или для кого?

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



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

Это смотря с чем сравнивать.
Самокат обычно ездит быстрее асфальтового катка. Тем не менее я предпочту либо велосипед, либо автомобиль.

   
 
 автор: Борис   (07.07.2007 в 15:53)   письмо автору
 
   для: Борис   (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 тысяч(образно)? Или я не правильно что-то понял....

   
 
 автор: Trianon   (07.07.2007 в 17:40)   письмо автору
 
   для: Борис   (07.07.2007 в 15:53)
 

>Также я пожертвовал нормализацией
Вот ключевая фраза.
Жертвовать нормализацией (если Вы не суперпрофессионал БД-разработчик) нельзя.
А если можно - то только очень осторожно - так чтобы при этом минимально страдала гибкость.
В частности общие поля объявлений вполне можно было вынести в одну таблицу, на чей первичный ключ сослаться чужими ключами из таблиц подкатегорий, если уж Вам так хотелоь работать с отдельными таблицами. Ссылка на первичный ключ - мгновенна.

   
 
 автор: stas1987   (07.07.2007 в 23:17)   письмо автору
 
   для: Trianon   (07.07.2007 в 17:40)
 

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

Или вы считаете, что рационально будет все объединить в одну?

   
 
 автор: Trianon   (08.07.2007 в 01:54)   письмо автору
 
   для: stas1987   (07.07.2007 в 23:17)
 

За какой период времени?
Если из них активно используется только 10% , таблицу лучше распилить по горизонтали, а не по вертикали. На активку и архив.
Ну и наконец, 100 тысяц - это не так много...
А по вертикали - распилить можно тоже, но не так, как у Вас.
А на столбцы, которые используются часто, и которые редко.

   
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования