- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Привет, подскажите пожалуйста, знающие люди - сколько полей сможет выдержать таблица базы прежде чем она "лопнет"?
Таблица автоматически пополняется новыми полями (столбцами).
Что то ничего не смог найти про это, может запрос не верно вбиваю...
ps вероятно убогое решение. Вообщем. Есть таблица с id товоров. Ежедневно появляется 1 новый столбец (поле). В этот столбец суммируется сегодняшнее количество резервирования того или иного товара.
сколько полей сможет выдержать таблица базы прежде чем она "лопнет"?
Для MySQL 5, MySQL 8
https://dev.mysql.com/doc/refman/8.0/en/column-count-limit.html
Однако, раз такое дело, может о структуре базы задуматься?
p.s. Есть ещё ограничение на размер строки https://dev.mysql.com/doc/refman/8.0/en/column-count-limit.html#row-size-limits
ivan-lev, спасибо. Размер строки - как я понял получаемых данных. В него мы не упремся, так как запрашивается только сегодняшняя колонка резервирований такого то id, прибавляется 1 и пишется новое число в сегодняшнюю колонку. Вчерашние и прошлые дни идут архивом.
Сегодня запрашивается только сегодняшняя колонка. Завтра будет новая.
А что можно тут придумать по структуре, может быть подскажете?
Честно говоря нет идей и мыслей, меня надо немного подтолкнуть к правильному решению.
Спасибо
ps вероятно убогое решение. Вообщем. Есть таблица с id товоров. Ежедневно появляется 1 новый столбец (поле). В этот столбец суммируется сегодняшнее количество резервирования того или иного товара.
эм, честно говоря до такого решения додуматься это еще надо уметь ))
недопустимая ошибка в базе - вторая таблица с тремя полями id товара, дата, резервирование, id и дата - индекс
Проще сделать таблицу из трех столбцов
id товара ( ключевое поле )
дата
кол-во резерва
тогда сайт будет жить вечно.
silicoid - а как это сделать....
потер, сперва не так понял
мне же нужно иметь отчет, по дням, т.е. в такой то день поставили такой то набор товаров в резерв, каждый столько то раз
Вот так нарисовал.
Если сегодня резервируют товар id4, то к 7 прибавится 1 и запишется 8.
А завтра уже новое поле, старт с нулями.
Для своего личного удобства сделано чуть иначе (свежая дата самая левая колонка), но сути не меняет.
мне же нужно иметь отчет, по дням, т.е. в такой то день поставили такой то набор товаров в резерв, каждый столько то раз
Вроде ж идею подсказали - отдельная таблица, куда скирдуешь изменения, связываешь либо с товаром, либо с набором товаров (тогда сделать отдельную таблицу набора).
Или нельзя создавать новые таблицы? Или я чота недопонял. :)
Вроде ж идею подсказали - отдельная таблица, куда скирдуешь изменения, связываешь либо с товаром, либо с набором товаров (тогда сделать отдельную таблицу набора).
Или нельзя создавать новые таблицы? Или я чота недопонял. :)
Типа как то так?
Проще сделать таблицу из трех столбцов
id товара ( ключевое поле )
дата
кол-во резерва
Или составной первичный ключ (id, date)
Типа как то так?
Типа да, только первый id в этом случае можно не использовать.
И определиться, может ли быть в один день несколько приходов.. )))
Можно на эту историю триггер повесить, который будет остатки в другой таблице (товаров) подсчитывать в соответствии с приходами-расходами.
первый id в этом случае можно не использовать
Лучше использовать, для удобства.