первая таблица где товары относятся к категории мебели,
вторая таблица для товаров для кухни
и третяя таблица для товаров электро-приборов
Это мне понятно. Но так получается - мы искусственно усложняем структуру БД. Создаем дополнительные таблицы, хотя с точки зрения решения задачи в них нет необходимости. Ведь для хранения информации о структуре каталога продукции достаточно двух таблиц (даже одной - но получится нерациональное расходование полей). Я здесь провожу аналогию с файловой системой - есть каталоги (директории) и есть файлы (почему я говорю - достаточно одной таблицы - потому что директория - это тоже файл, только особого вида).
1;6;Извещатель охранный магнитоконтактный ИО 102-2;Технические характеристики ИО 102-2;1
2;6;Извещатель охранный магнитоконтактный ИО 102-4;Технические характеристики ИО 102-4;2
3;6;Извещатель охранный магнитоконтактный ИО 102-14;Технические характеристики ИО 102-14;3
4;7;Извещатель охранный электроконтактный ИО 201-1;Технические характеристики ИО 201-1;1
5;7;Извещатель охранный электроконтактный ВПК 2112;Технические характеристики ВПК 2112;2
6;8;Извещатель охранный ударноконтактный "Окно-4";Технические характеристики "Окно-4";1
7;8;Извещатель охранный ударноконтактный "Окно-5";Технические характеристики "Окно-5";2
8;8;Извещатель охранный ударноконтактный "Окно-6";Технические характеристики "Окно-6";3
9;9;Извещатель пожарный тепловой ИП 114-01;Технические характеристики ИП 114-01;1
10;9;Извещатель пожарный тепловой ИП 101-1A;Технические характеристики ИП 101-1A;2
11;9;Извещатель пожарный тепловой ИП 101-30;Технические характеристики ИП 101-30;3
12;10;Извещатель пожарный дымовой ИП 212-3СМ;Технические характеристики ИП 212-3СМ;1
13;10;Извещатель пожарный дымовой ИП 212-18СИ;Технические характеристики ИП 212-18СИ;2
14;11;Извещатель пожарный комбинированный ИП 212/101-78-А1;Технические характеристики ИП 212/101-78-А1;1
15;11;Извещатель пожарный комбинированный ИП 212/101-18 А3R1;Технические характеристики ИП 212/101-18 А3R1;2
В этих двух таблицах я могу хранить каталоги продукции 2, 3, 10, 20 разных фирм (одно условие - придется добавить дополнительное поле - идентификатор фирмы, которой принадлежит категория или товар).
Мне интересно знать, как разбить эти таблицы, если они слишком разростутся (или будут изначально велики)? Получается, я должен буду изменить все запросы к этой таблице (а точнее - уже к трем), если разобью ее на части?
P.S. Почему я проявляю столь живой интерес к этой теме - просто много раз слышал о проблеме большого количества записей. И хочется быть готовым к этой ситуации, если она вдруг случится.
Цитата:
Дело в том что в 15 000 строковой таблице будет слишком много строк удовлетворяющих условие Char = A & num = 1 , поэтому системных ресурсов для вычисления и запоминания, а потом сортировки по этому числу - уходить будет очень много.
Можно ещё сделать чтото вроде такого:
SELECT * FROM `table` WHERE `char`='A' AND `num`=1 AND `id`=$rnd
и повторять эту комбинацию циклом while пока из базы чтото не выберется.
Согласен. Единственно, что я бы еще сделал - попробовал все варианты и засек бы время на выплнение. Но это не дает никаких гарантий - потому как у разных хостеров может быть по-разному. У одного PHP и MySQL на одной машине, у другого - на разных. И т.п.
(Добавление)
Мне не спится. Поэтому продожу. Пусть у нас есть фирма, которая предоставляет услуги хостинга и одновременно - услуги создания сайтов. Каждый сайт, создаваемый этой фирмой имеет каталог продукции (может быть и с Интернет-магазином). Все сайты работают на одном движке. Вся информация о продукции этих фирм хранится в двух таблицах CATEGORIES и PRODUCTS. Чтобы не заморачиваться каждый раз с модификацией движка (передавая в запросы уникальный идентификатор фирмы id_firm), эта фирма создает в БД представления (view)
CREATE VIEW CATEGORIES_FIRM1 AS
SELECT * FROM CATEGORIES WHERE id_firm=1
CREATE VIEW PRODUCTS_FIRM1 AS
SELECT * FROM PRODUCTS WHERE id_firm=1
CREATE VIEW CATEGORIES_FIRM2 AS
SELECT * FROM CATEGORIES WHERE id_firm=2
CREATE VIEW PRODUCTS_FIRM2 AS
SELECT * FROM PRODUCTS WHERE id_firm=2
CREATE VIEW CATEGORIES_FIRM3 AS
SELECT * FROM CATEGORIES WHERE id_firm=3
CREATE VIEW PRODUCTS_FIRM3 AS
SELECT * FROM PRODUCTS WHERE id_firm=3
А потом достаточно создать файл конфигурации config.ini следующего содержания
define("CATEGORIES", "CATEGORIES_FIRM1");
define("PRODUCTS", "PRODUCTS_FIRM1");
для первой фирмы
define("CATEGORIES", "CATEGORIES_FIRM2");
define("PRODUCTS", "PRODUCTS_FIRM2");
для второй фирмы
и т.д.
А в самом движке при необходимости обращения к таблице товаров пишем
$query = "SELECT id_prd, title, description, price FROM ".PRODUCTS." WHERE id_prd=".$id_prd;
При этом для первой фирмы будет идти обращение к представлению PRODUCTS_FIRM1, для второй - к PRODUCTS_FIRM2 и т.д.
Вопрос, который я хотел задать - если таблица PRODUCTS становится слишком велика - как ее грамотно разбить на части и как к эти частям обращаться?
Я еще спросить хотел. По поводу разбить талицу на "кусочки".
Вот, положим, у меня есть таблица, где хранится информация о продукции некоторой фирмы. Содержит 15000 записай. Я ее разбил на три - по 5000 записей в каждой. Я вроде слышал, что для MySQL это полезно. Но как работать с этими таблицами?
Пока таблица была одна, я мог составить запрос для получения одной записи
SELECT title, description, price, image FROM products WHERE id_product=1001
А как быть, если я одну таблицу разбил на три? Составлять запрос типа
SELECT title, description, price, image FROM products1 WHERE id_product=1001
UNION
SELECT title, description, price, image FROM products2 WHERE id_product=1001
UNION
SELECT title, description, price, image FROM products3 WHERE id_product=1001
(Добавление)
valenok пишет:
Давай тогда ещё раз.
Что у нас происходит когда мы выполняем следующий запрос: ?
SELECT * FROM `table` WHERE `char`='A' AND `num`=1 ORDER BY RAND() LIMIT 1
Я так понимаю, что из таблицы выбираются записи, удовлетворяющие условию WHERE `char`='A' AND `num`=1. При этом, для каждой записи высисляется значение RAND() и по нему идет сортировка
mysql' овский RAND() возвращает число от 0 до 1
Для того наш rand я и поделил на 10 000
Да, я понял. Но суть дела это не меняет - нельзя сортировать записи по константе 0.1234
SELECT * FROM `table` WHERE `char`='A' AND `num`=1 ORDER BY 0.1234 LIMIT 1
Выражение ORDER BY 0.1234 не имеет смысла - запросы
SELECT * FROM `table` WHERE `char`='A' AND `num`=1 ORDER BY 0.1234 LIMIT 1
SELECT * FROM `table` WHERE `char`='A' AND `num`=1 LIMIT 1
вернут одинаковые результаты.
Что-то я твою идею не понял. Пусть $rnd = rand(). Т.е. это - число.
Тогда запрос будет выглядеть так
SELECT * FROM `table` WHERE `char`='A' AND `num`=1 ORDER BY 1234 LIMIT 1
При запросе
SELECT * FROM `table` WHERE `char`='A' AND `num`=1 ORDER BY RAND() LIMIT 1
функция MySQL RAND() для каждой записи выбирает случайное число - по нему и идет сортировка. А как сортировать по константе? Другими словами ORDER BY 1234 не имеет смысла и MySQL будет все время возвращать одну и ту же запись (до тех пор, пока мы не модифицируем таблицу - добавим/удалим записи)
P.S. А задачка оказалась совсем не такой тривиальной...
А если у меня диапозон айпи типа 77.235.9.128 - 77.235.9.150
Врать не буду - ни разу с таким не сталкивался. Но думаю, в этом случае придется перечислять все IP
allow from 77.235.9.128
allow from 77.235.9.129
allow from 77.235.9.130
................................ ..
Блин, я так понимаю - мы тут все "большие" специалисты по настройке Apache.
P.S. Я тут быстро просмотрел по Интернету - записи типа
allow from 127.0.0.0 - 127.0.0.32
не разрешаются. Ты говоришь, у тебя работает. Тогда, возможно, еще нужно учитывать версию Apache 1.x или 2.x
Да в принципе информация в Интернете есть, надо только систематизировать
Цитата:
Order deny,allow
Deny from all
Allow from 62.148.3.4
Allow from 62.148.10
Строка Allow from 62.148.10 - открывает доступ для всех клиентов с адресами, начинающимися с 62.148.10
Цитата:
Что-то я никак не пойму - как запретить доступ всем, с подсетей, скажем,
200.*.*.*
201.*.*.*
202.*.*.*
Вообще. Напрочь. К сайту.
-------------------------------- -------------------------------- ---------------
Просто перечисляете запрещаемые подсети - по одной в строке
Знаешь, не смешно. Очень уважаю людей, которые тратят свое время на то, чтобы помочь другим людям. Безвозмездно, т.е. даром Смеяться над этим грешно. Им вообще памятники надо ставить. Из гранита. На них мир держится.
P.S. Сам тратишь свое время на помощь людям - и над такими же как ты прикалываешься.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 1209
Смеяться над этим грешно. Им вообще памятники надо ставить. Из гранита. На них мир держится.
