Правильно ли я выбрал структуру базы данных, создав 2500 одинаковых таблиц?

Question

[Andrew_Novikov]

Делаю свой pet-проект. На локальном компе (Windows) написал сложный алгоритм, который взаимодействует с MySQL. К регистру вводимых данных серьезно не относился. Загрузил на VPS сервер и полетели ошибки. Первая проблема - это чувстительность к регистру в MySQL на сервере с Debian. В интернете есть решения по типу прописать в файле lower_case_table_names = 0 , запуск демона mysqld с параметром -O lower_case_table_names=1 и т.д. В результате навернулась БД, и упал сайт... Если не сложно, поделитесь простой проверенной инструкцией, как сделать mysql на сервере не чувсивтельным к регистру.

Comments

[maksam07]

Таблицы в какой кодировке? Они точно так же настроены, как и в вин?

[mayton2019]

А в какой части разработок у тебя были разные регистры символов? В именах таблиц?

[Andrew_Novikov]

mayton2019, название бд и имена таблиц. Если с названием БД можно не париться, а поменять одну переменную в алгоритме, то на вводимых именах много чего в коде завязано. Пользователь выбирает имя спортсмена, например "Petr_Yan", дальше идет запрос к БД "select * from Petr_Yan", и на локалном компе все хорошо работает. На сервере выдает ошибку, мол такой таблицы не сущесвтует. Сменил на нижний регистр "petr_yan" и MySQL на сервере эту таблицу видит.
Варианта два пока нашел: 1. Переписать алгоритм, чтобы имена были в нижнем регистре (долго). 2. Убрать у MySQL на сервере чувствительность к регистру (но этот вариант пока провалился)

[Andrew_Novikov]

maksam07, проблема в том, что я не знаю. Мало опыта работы с БД. При выгрузке БД с локального компьютера пользуюсь программой HeildiSQL и не смог найти там записи о кодировке. Загружаю ее на сервер через SSH подключение и все названия (бд, таблицы) загружаются в нижнем регистре. А какая кодировка у всего этого добра я нигде не заметил

[Slava Rozhnev]

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

[Andrew_Novikov]

Slava Rozhnev, ну ок, буду думать, как это исправить

[Slava Rozhnev]

Andrew_Novikov, Вам нужна одна таблица для всех спортсменов из которой вы будете выбирать по имени
select * from sportmens where name = 'Petr_Yan'

[Ипатьев]

"select * from Petr_Yan", извините, но это какой-то бред.
Начиная с имени спортсмена, как у какого-нибудь рептилоида, и заканчивая кривой структурой БД
Сколько у вас записей в этой таблице?

[Ипатьев]

Slava Rozhnev, я думаю, что скорее там должно быть что-то вроде
select * from fights where athlete_id=22

Ну или

select * from athletes where name like '%petr%' or name like '%yan%'

[Andrew_Novikov]

Ипатьев, так, грубо говоря я пытаюсь собрать онлайн дашборд исходя из запроса пользователя. Есть три базы данных. В первой БД хранятся 2 500 таблиц названия - это имена спорстменов. Внутри у каждой таблицы от 2 до 50 записей внутри. Это их показатели в конкретной встрече. И при запросе пользователя, я вывожу все записи из этой таблицы + делаю запросы из двух других БД, где есть его статистические показатели. Как бы Вы в таком случае построили структуру БД?

[Ипатьев]

Andrew_Novikov, вам сначала надо понять что это не вопрос мнений.
Это все равно что спросить "а сколько по-вашему будет дважды два?"
Это не как будет "по-моему", а какой будет единственно правильный ответ.

Вместо 100500 таблиц должно быть ДВЕ.
В одну пишется информация о спортсмене. Назовем её athletes. Кроме имени и других очевидных полей в ней должно быть уникальное автоинкрементное поле id.
Во второй должна быть информация из всех этих ваших таблиц, плюс значение id соответствующего спортсмена из таблицы athletes.
И выбирать из неё запросом, который я привел выше.

Плюс надо посмотреть что у вас там в еще двух базах данных. и явно перенести все в одну

[Andrew_Novikov]

Ипатьев, понял, буду думать

[Ипатьев]

Плюс если вы пишете на РНР, то в обязательном порядке использовать подготовленные запросы.

[Ипатьев]

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

[Ипатьев]

Кстати, у вас сейчас информация о боях дублируется, правильно?
А она не должна.
То есть в таблице fights должно быть два id бойцов,
И соответственно запрос должен быть WHERE athlete_id1=22 or athlete_id2=22
таким образом получим все бои в которых он участвовал.

[Andrew_Novikov]

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

[Ипатьев]

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

[Andrew_Novikov]

Ипатьев, я написал парсер, который берет данные их поединка. Те удары, тейкдауны и прочее, которые нанес Ян идут в его таблицу, те, что нанес Стерлинг идут в таблицу Стерлинга. Если мне нужно узнать, сколько ударов пропустил Ян в том поединке, я просто пишу запрос по типу "select * from aljamain_sterling where opponent='petr_yan'" или что-то в этом духе. Если мне нужно получить показатели защиты за все время, то я просто вытаскиваю имена всех бойцов, с которым он встречался, и по циклу их прогоняю как в предыдущем запросе. В целом, так и получается, что каждая таблица содержит уникальные значения

[Ипатьев]

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

[Andrew_Novikov]

Ипатьев, да, есть такие показатели, их получается 6-7 столбцов из 58. Победитель, время, метод, имена судей. Получается, что они дублируются. Я по началу не придумал, как их вынести. Хотел отдельную таблицу создать по ивентам, а потом решил не париться и прописывать их у кахжого бойца в его таблице. С одной стороны это увеличило размер БД (она поличилась под 44 мб) с другой упростила жизнь при анализе данных ( не надо было придумывать сложные запросы, а просто импортировать сразу данные и с ними работать)

[Ипатьев]

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

[Andrew_Novikov]

Ипатьев, не спорю. Там еще много, где можно улучшать и улучшать. Но никому мои наработки не понравились, чтобы делать проект со мной. А тех денег, что запрашивали за создание MPV у попросту нет))) так что приходится придумывать все самому)))

[Ипатьев]

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

[Максим Федоров]

Не надо плодить таблицы лол

Сделайте users: id, name, alias

И работайте с ней в р таблицах через джойны и user_id

Answer 1

[mayton2019]

Andrew_Novikov,

Пользователь выбирает имя спортсмена, например "Petr_Yan", дальше идет запрос к БД "select * from Petr_Yan",

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

Над таблицами думают. Их рисуют на архитектурных диаграммах. Ты чисто случайно словил
дефект в различиях файловых систем Linux/Windows и мы пришли вообще к тому что ты
сделал невернй дизайн БД.

После того как переделаешь - проблема сама собой уйдет. А когда будешь придумывать
имена таблиц - делай все в одном регистре. Так - проще жить. Меньше в будущем
будет архитектурных косяков.

Comments

[Andrew_Novikov]

Ну ок, видимо пока вариант первый, переписать все, чтобы было в нижнем регистре, и посмотреть как будет фурычить. А по поводу архитектуры БД, то были такие подозрения, что не будет хватать мощностей сервера. Отсюда другой вопрос, как тогда существуют приложения, формирующие целые дашборды на запрос пользователя? Где строятся и обрабатывается их информация, которая передается фреймворку?

[Ипатьев]

Это хороший ответ, но под него надо редактировать заголовок вопроса
иначе этот пост превратится в то, за что мы все так ненавидим Q&A сайты, когда пытаемся гуглить ответ на свой вопрос

[Ипатьев]

Andrew_Novikov, вы не поняли.
Проблема не в сервере. Под ваши задачи даже утюг подойдет в качестве сервера.
Проблема в том что у вас, если говорить прямо, идиотская структура БД.
Это нормально для самоучки. Все с этого начинают.
Но вот что ненормально - это то, что вы за нее держитесь, и вместо того чтобы сделать по-человечески, пытаетесь подставить какой-нибудь костыль

[mayton2019]

Ипатьев, так часто бывает. Заскочишь в больничку сделать флюрографию. А на следующий
день врач тебе говори - присядьте пожалуйста. Нам с вами есть что обсудить по вашему здоровью.... :)

[Ипатьев]

именно поэтому это должен быть комментарий, а не ответ

[mayton2019]

Ипатьев, как барину будет угодно.

Answer 2

[Alexey Dmitriev]

Простая и проверенная инструкция - "как сделать mysql на сервере не чувствительным к регистру" - это понимать, как работает mysql.
В нем есть кодировки и collation - CI (Case Insensible - не чувствительный к регистру) и CS (Case Sensible - Чувствительный к регистру).
Собственно вам нужно обеспечить поддержку кодировки символов CI

Comments

[Akina]

Всё написанное Вами относится к данным и никакого отношения к работе с метаданными не имеет.

[Ипатьев]

и это называется не кодировкой, а таблицей сравнения - collation.
и ещё, Insensible - это не то что вы думаете. Бесчувственный это совсем не то же самое, что нечувствительный ;)