Посоветуйте по проектированию БД

Здравствуйте, коллеги!

Вот такая вот задачка возникла у меня.

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

Вопрос - как эффективно реализовать БД с такой нагрузкой?

Создавать каждый раз табличку с номером и писать в нее только ее уникальные записи - не удобно. Слишком много таблиц.
Создать одну таблицу и писать в нее все записи - не эффективно. 1000x1000 - уже миллион записей.

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

Значение 300 000 взято условно конечно.

Может кто подскажет более рациональное решение? Буду весьма благодарен.

Цитата ("nolesxp"):

Создать одну таблицу и писать в нее все записи - не эффективно. 1000x1000 - уже миллион записей.

Напугали и по несколько миллиардов видел таблицы, и ничего, работали. Если грамотно делать выборку и проставить индексы - пофиг сколько в таблице записей

Нормализуйте отношения хотя бы до 3 нормальной формы

Какого рода записи? Что за СУБД? И оно действительно начинает валиться от миллиона, двух, миллиарда наконец записей?? Вы проверяли это?...
Вариант с табличками по 300 000 - по сути наворачивание сверху уже достаточно продуманной системы БД какой то свой костыль. Либо пользуйтесь встроенными средствами(индексации и так далее), либо пишите свою БД - возможно в вашем случае это будет и рациональней.

База данных mysql, поиск выполняется по всем столбцам а их порядка 30. Соотвественно идут постоянные различные выборки по 30 полям 1 млн записей, при одновременных различных запросах даже от 100 пользователей тормозит прилично.
Пример записей:
id,date,num,filed,filed,filed,filed,filed,filed,filed,filed,filed,filed
1000001,10241232151,15554, 1.8 ,115.34, 1.8 ,1115.34, 1.8 ,1135.34, 1.8 ,11215.34, 1.28 ,1151.34, 1.8 ,115.34, 1.87 ,12.34, 1.8 ,115.34, 1.8 ,115.34, 13.8 ,1151.34, 122.8 ,15.34, 112.8 ,1151.34, 111.8 ,115.34
1000002,12321541878,15156, 1.8 ,115.34, 1.8 ,1115.34, 1.8 ,1135.34, 1.8 ,11215.34, 1.28 ,1151.34, 1.8 ,115.34, 1.87 ,12.34, 1.8 ,115.34, 1.8 ,115.34, 13.8 ,1151.34, 122.8 ,15.34, 112.8 ,1151.34, 111.8 ,115.34
..

Забыл сказать что это веб приложение. Т.е запросы отправляются к БД через PHP.

Какая схема (структура) БД?. ER - диаграмма?

Цитата ("sergannd_snz"):

Нормализуйте отношения хотя бы до 3 нормальной формы

Хороший совет

Буду краток: посилання

Цитата ("MMM_Corp"):

Буду краток: ]https://www.weblancer.net/users/MMM_Corp/portfolio/401825.html

Краткость - сестра таланта(?):

Цитата:

Ошибка 404: Страница не найдена

Запрашиваемая Вами страница не существует или была переименована.
Пожалуйста, проверьте правильность написания адреса либо обратитесь в службу поддержки за консультацией.

Цитата ("nolesxp"):

...
Может кто подскажет более рациональное решение? Буду весьма благодарен.

По каким критериям надо "рационализировать": объем диска, скорость доступа, безопасность, что-то еще? Методы "рационализации" сильно зависят от критериев, напрмер, предложенный Вами подход будет работать не очень быстро, особенно при использовании таблиц MyISAM (создание таблицы - это медленная операция), будет иметь определенные слабости в отношении безопасности (если Ваша программа может создавать таблицы, то существует принципиальная возможность того, что ее можно будет заставить создать очень много таблиц, так много, что окажется заполненной файловая система) и по сопровождению (если какая-то программа что-то создает, то потом кто-то это что-то должен будет убирать).

Странно, а у меня нормально все открылось

Цитата ("nolesxp"):

id,date,num,filed,filed,filed,filed,filed,filed,filed,filed,filed,filed
1000001,10241232151,15554, 1.8 ,115.34, 1.8 ,1115.34, 1.8 ,1135.34, 1.8 ,11215.34, 1.28 ,1151.34, 1.8 ,115.34, 1.87 ,12.34, 1.8 ,115.34, 1.8 ,115.34, 13.8 ,1151.34, 122.8 ,15.34, 112.8 ,1151.34, 111.8 ,115.34
1000002,12321541878,15156, 1.8 ,115.34, 1.8 ,1115.34, 1.8 ,1135.34, 1.8 ,11215.34, 1.28 ,1151.34, 1.8 ,115.34, 1.87 ,12.34, 1.8 ,115.34, 1.8 ,115.34, 13.8 ,1151.34, 122.8 ,15.34, 112.8 ,1151.34, 111.8 ,115.34

Сделайте одну табличку вида id,num
Вторая остается в текущем виде, за исключением того, что теперь в столбец num будет идти не сам номер, а его id из первой таблицы. У этой таблицы добавьте индекс столбца num.

Тогда можно будет делать запросы, например, в виде SELECT table2.* FROM table2 AS table2 LEFT JOIN table1 AS table1 ON (table1.id=table2.num) WHERE table1.num=$num

P.S. Миллионы записей при правильном индексе - миллисекунды запроса, не более. Вы даже можете на свою текущую таблицу навесить индекс на num и уже увидите колоссальный прирост производительности.

Цитата ("Illarion_SA"):

Цитата ("MMM_Corp"):

Буду краток: ]https://www.weblancer.net/users/MMM_Corp/portfolio/401825.html

Краткость - сестра таланта(?):

Цитата:

Ошибка 404: Страница не найдена

Запрашиваемая Вами страница не существует или была переименована.
Пожалуйста, проверьте правильность написания адреса либо обратитесь в службу поддержки за консультацией.

сцылка коректная... незнаю что там у вас не открылось....

в общем по САБЖУ, заведите себе правило:
1. первое поле в табл. ключ + индекс, всегда!
2. неплодите много табл. плодите грамотные запросы, вюхы, хранимкы
3. всегда смотрите план выполнения запроса, анализируйте его, экпериментируйте между прямим джойнами и вхере
4. удаляйте мусор регулярно, в мускуле есть планировщик юзайте его
5. хранимка всегда выполнится быстрее чем прямой запрос!!! этим правилом вебщики в 99% случаев игнорируют, и в 90% не знают что такое хранимка, не обижайтесь, но это из реальной жизни
6. есть и более прогресивные СУБД - MSSQL, PostGresSQL
7. кластера, увеличение ОЗУ тоже как вариант, но єто уже более радикальные меры

по вашей задаче - у вас классика вида - мастер-детайл, 2 табл. больше не нужно

Цитата ("MMM_Corp"):

этим правилом вебщики в 99% случаев игнорируют, и в 90% не знают что такое хранимка, не обижайтесь, но это из реальной жизни

mysql на хостингах может быть и третьей версии.

Цитата ("werewolf"):

Цитата ("MMM_Corp"):

этим правилом вебщики в 99% случаев игнорируют, и в 90% не знают что такое хранимка, не обижайтесь, но это из реальной жизни

mysql на хостингах может быть и третьей версии.

Это уже маловероятно

Цитата ("werewolf"):

Цитата ("MMM_Corp"):

этим правилом вебщики в 99% случаев игнорируют, и в 90% не знают что такое хранимка, не обижайтесь, но это из реальной жизни

mysql на хостингах может быть и третьей версии.

неужели найти хостинг такой дефицит, что выбирать те, у кого 3й мускуль стоит. Я сейас вообще переборчив стал, и только 5 выбираю, слава богу выбора хватает, а стоит хостинг копейки по сравнению с остальными затратами на проект.

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

Цитата ("ypeskov"):

неужели найти хостинг такой дефицит, что выбирать те, у кого 3й мускуль стоит. Я сейас вообще переборчив стал, и только 5 выбираю, слава богу выбора хватает, а стоит хостинг копейки по сравнению с остальными затратами на проект.

Заказчик - барин. Хостинг он, вероятно выбрал уже.

Цитата ("werewolf"):

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

Инерция, конечно, сильный фактор, но кроме того:

1. Для того чтобы хранимые процедуры можно было вести в системе управления версиями (CVS, SVN и пр.) нужны какие-то дополнительные программы и процедуры.

2. Хранимые процедуры (на MySQL) хранятся в БД mysql, если Вы не озаботитесь регулярным копированием этой базы (а Ваш провайдер может и не дать Вам прав доступа к ней), то когда у провайдера что-то сломается и они будут восстанавливать БД "по кусочкам", есть шанс, что все хранимые процедуры скажут bye-bye. Кстати, все-ли провайдеры копируют таблицу mysql.proc?

3. В документации MySQL 5.x список ограничений по работе с хранимыми процедурами и функциями имеет впечатляющую длину. У меня сложилось впечатление, что в mysql за каждым ограничением скрывается, по крайней мере, одна ненайденная ошибка. Конечно, каждый сам решает стоит-ли искать приключений, там где их можно не искать.

4. При реплицировании БД между MySQL разных версий с хранимыми процедурами могут возникнуть проблемы. То же при обновлении MySQL, напр. с 5.0 на 5.1.

Цитата ("werewolf"):

Хотя тут еще дело в непрофессионализме в среде пхпшников.

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

Спасибо, всем кто отписал, особенно MMM_Corp!