Форум PHP программистов > Как сделать выборку шести таблиц и отсортировать

[ Поиск ] - [ Пользователи ] - [ Календарь ]

Полная Версия: Как сделать выборку шести таблиц и отсортировать

exotica

30.10.2014 - 14:00

Доброго времени

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

т.е. есть таблицы в БД такого вида
| id | name | date |
| 1 | n1 | 10.01.2014 |
| 2 | n2 | 14.01.2014 |

| id | name | date |
| 1 | n3 | 8.01.2014 |
| 2 | n4 | 11.01.2014 |

Нужно выбрать все, и в браузер отдать в таком виде

1 | n3 | 8.01.2014
1 | n1 | 10.01.2014
2 | n4 | 11.01.2014
2 | n2 | 14.01.2014

т.е. отсортированное по дате, независимо от уникального ИД каждой таблицы

_____________
[FAQ]Регистрации пользователей, сохранение в БД
---------------------------------------------------------------------------
Выходя из ванной, вышел из нее два раза

kaww

30.10.2014 - 14:08

http://www.mysql.ru/docs/man/UNION.html

sergeiss

30.10.2014 - 16:14

Цитата (exotica @ 30.10.2014 - 14:00)

Нужно сделать выборку из шести таблиц с одинаковой структурой...

Ты уверен, что у тебя правильная структура таблиц? Наличие 6 идентичных таблиц "наводит на мысль" о том, что их лучше объединить в одну.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

exotica

30.10.2014 - 16:22

sergeiss хотелось изначально одной обойтись. Но не нашел решения как получить в этой одной таблице 000001-999999 уникальных значения для каждой из 6-ти разных категорий.

_____________
[FAQ]Регистрации пользователей, сохранение в БД
---------------------------------------------------------------------------
Выходя из ванной, вышел из нее два раза

exotica

30.10.2014 - 16:27

Вродебы все и просто:
| id | category | number | ... | ... |

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

_____________
[FAQ]Регистрации пользователей, сохранение в БД
---------------------------------------------------------------------------
Выходя из ванной, вышел из нее два раза

sergeiss

30.10.2014 - 17:18

Цитата (exotica @ 30.10.2014 - 16:22)

Но не нашел решения как получить в этой одной таблице 000001-999999 уникальных значения для каждой из 6-ти разных категорий.

Тебе критично, чтобы для каждой из 6 категорий были уникальные значения именно в этом диапазоне? Если да, то почему так? Почему является проблемой наличие "пустот" в нумерации для каждой определенной категории?

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

Alchemist

30.10.2014 - 17:48

Фин. документы, например, в отчете должны иметь последовательные уникальные номера, чеки на кассе в магазине, автобусные билеты в рулоне и т.д., примеров на самом деле масса...

Другое дело - должен ли этот номер быть ID. Есть куча вариантов ручной эмуляции auto_increment.

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

sergeiss

30.10.2014 - 18:27

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

Ждем-с ответа от ТС, зачем ему это нужно:)

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

inpost

30.10.2014 - 19:20

exotica
Ты про составной UNIQUE индекс по двум полям? Тогда будет уникальное. А насчёт эмуляции автоинкремента - там ничего сложного MAX(`id`) + 1.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

exotica

31.10.2014 - 11:04

sergeiss
Нужно именно для каждой категории в диапазоне от 1 до 999999.
Но вот проблема с которой столкнулся. Одновременно в базе никогда не будет 999999 позиций,
счет должен идти до 999999, после достижения должен занимать первое по порядку пустое значение и записывать позицию в него. (т.к. товар приходит и уходит) т.е. по факту должна делаться запись на первый свободный ID в диапазоне 1-999999

inpost
Спасиб зачитаю подробности

_____________
[FAQ]Регистрации пользователей, сохранение в БД
---------------------------------------------------------------------------
Выходя из ванной, вышел из нее два раза

sergeiss

31.10.2014 - 12:06

Цитата (exotica @ 31.10.2014 - 11:04)

Нужно именно для каждой категории в диапазоне от 1 до 999999.
Но вот проблема с которой столкнулся. Одновременно в базе никогда не будет 999999 позиций,
счет должен идти до 999999, после достижения должен занимать первое по порядку пустое значение и записывать позицию в него. (т.к. товар приходит и уходит) т.е. по факту должна делаться запись на первый свободный ID в диапазоне 1-999999

1-999999 - это всего миллион записей. Для 6 категорий - 6 млн. записей. Можно изначально, в одной таблице, создать эти миллионы записей

В каждой записи ключевыми будут 3 поля: айди, номер категории и индикатор занятости позиции. Заодно сразу же разделить на партиции, по номеру категории.

При таком подходе, конечно, ты сразу же достигаешь максимального объема БД. Но зато очень удобно работать.
* Надо найти первый незанятый айди для категории 3? Элементарно: всего один простой запрос.
* При вставке и удалении реальных данных достаточно будет апдейтить уже существующие записи

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

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

exotica

31.10.2014 - 15:17

sergeiss
Это так сказать самостоятельная работа для повышения собственной уверености, сбора дополнительных знаний, а также определенной прибыли и дальнейшего сотрудничества с людьми нуждающимеся в данной системе.

Делаю так сказать "интерфейс" склада, для интернет магазина. Т.е. сам инт-магаз работает самостоятельно без моего вмешательства, там отдельный человек для этого.

В моем случае склад должен представлять следующие возможности:

Все товары разбиты на 6 категорий (такая разбивка произошла ввиду сходства характеристик товаров, и чтобы при заполнении не листать html таблицу из 29 полей ввода, было разбито на 6. В итоге товар попадающий под определенную категорию требует к заполнению не 29 полей, а всего от 4 до 6, в итоге средствами php составляю таблицу полей подходящюю для выбранной категории).
Новая позиция добавляется хозяйвами там где происходит обмерка и фотография этой позиции. И по умолчанию имеет статус "in Storage only". Вся форма заполняется быстро без лишних движений, используя Tab попорядку записываются диктованые характеристики. Самой медленной и время отнимающей операцией пока является выбор и загрузка фотографий (но есть идеи как сократить ее в несколько раз, пока не занимался). Обработчик получив submit от формы, проверяет поля, те значения которые не указаны отправляются в бд как пустые ' '. Фотографии с студии размером в 5+ мб пропорционально сжимаются до максимально возможного для показа формата веб-магазина, и сохраняются. В ответ обработчик отдает уникальный номер для того чтобы он был отпечатан нумератором на наклейке, а та в свою очередь клеится на товар - товар идет на полку.
Далее для людей работающих где удобно, т.е. на основных работах, дома, и т.д. Storage(внутренее название разрабатываемой системы) показывает те позиции у которых статус "in Storage only" . Они открывают веб-магазин, и добавляют новый товар в уже на общее обозрение , выбирая все данные из записи в Storage , а также фотографии, которые после обработки весят уже <500кб .

Из дополнительных возможностей:

Поиск по артикулу (типа А000001) выдает всю информацию об этой позиции имеющююся в Storage, также отправляет запрос к магазину и получает всю системную информацию об этой позиции. Так же без преходов отображает карточку этого товара, так как она видна покупателям.
Список всех позиций в базе выводит как абсолютно все, так и можно выбрать по категориям, статусу или дате.
Благодаря сессии конкретный авторизовавшийся пользователь может настроить весь функционал сайта под себя любимого. Т.е. если добавляют допустим 50 курток Мужских и Отличного состояния. Достаточно поставить галку рядом с селектом и в следующий раз все будет уже выбрано, Но при условии что будет заполнятся форма именно для категории товаров к которой подходят крутки.

С чем ломаю голову в нынешнее время:

Структура таблиц, или же запрос для вывода "Всех позиций"(о чем собственно и тема)
Загрузка фото методом "из папки потянул, мышку отпустил - пошла загрузка" , а также незамедлительным отображением превью новой фотографии (думал но работаю с бд, она важнее)
Подключение к БД и системе веб-магазина для реализации API позволяющего менеджерам публиковать товары из Storage за пару кликов.(пока вообще не думал)

Позже приглашу, и вышлю в ЛС лог-пасс для желающих. Открытого доступа не будет, для всех включая поисковиков будет "Deny for all" . Кроме самого склада, и менеджеров. Доступ которых будет определен по ряду параметров.

_____________
[FAQ]Регистрации пользователей, сохранение в БД
---------------------------------------------------------------------------
Выходя из ванной, вышел из нее два раза

Быстрый ответ:

Здесь расположена полная версия этой страницы.