kursof: ну как-то так примерно: SELECT DATE_SUB(NOW(),INTERVAL 30 DAY) AS new_date -- это просто для теста (что бы Вы видели, что за значение получается)
DELETE FROM table_name WHERE date_column <= DATE_SUB(NOW(),INTERVAL 30 DAY)
-- я не проверял, но думаю должно работать... Если у Вас столбец с просто датой, а не с дата-временем, то будет примерно так:
DELETE FROM table_name WHERE date_column <= DATE(DATE_SUB(NOW(),INTERVAL 30 DAY))
хотя и предыдущий вариант тоже сработает скорее всего, в MySQL по моему дата автоматиеские приводится к дате-времени, при подобных условиях
Станислав Почепко: Тогда это уже целиком базу дампить нужно, я думаю, вместе с данными. Можно в репозиторий... Другое логирование я себе едва ли представляю... Хотя, можно конечно конечно, ковырять лог самой БД, но она и так и эдак его ведёт, хочет того пользователь или нет...
Станислав Почепко: я думаю, единственный вменяемый способ в таком раскладе - это либо миграции ларавеля, либо дамп БД без данных (дамп структуры) в GIT-репозиторий. В принципе, если без данных, думаю миграции отлично подойдут.
Павел: я месяц пользуюсь ноутбуком с HDD на 5400 (в виду разъездов), и не смотря на 4-х ядерный процессор, это просто какой-то ад. Положение немного спасла установка линукса, но желание выкинуть оттуда стандартный диск и воткнуть SSD, меня не покидает и будет осуществлено как только я буду рядом с ближайшим официальным сервис. центром (что бы гарантию не убить).
Z-r: а) "к экземпляру должен прилагаться соответствующий полный исходный текст в машиночитаемой форме, который должен распространяться в соответствии с условиями п.п. 1 и 2 настоящей Лицензии на носителе, обычно используемом для передачи программного обеспечения"
Не совсем понимаю, каких именно "таких" условий там нет, но есть очень много ПО, производного от другого ПО, ранее выпущенного под лицензией GPL, в т.ч. базы данных (MySQL, как вариант + множество её форков: Percona, MariaDB и т.д.) которые идут так, с открытым исходным кодом и всеми прочими плюшками из этого вытекающими.
Alter-ego: с большей вероятностью - "втыкание УСБ-Блютуз адаптера" в порты телевизора - ничего не даст, но... попробовать стоит. Вообще, об этом в документации к телевизору пишут, типа "список совместимых устройств" и т.д. Некоторые энтузиасты запускают на телевизоре скайп и даже подключают вебкамеру...
Памяти 8Гб, 2xSSD, на сервере FreeBSD + Posrgres. Касательно объёмов БД пока сказать не могу, доступа к серверу с того места где я сейчас, но пока всё работает в пределах нормы. Запросы в пределах 1сек. выполняются.
Не знаю как обозначить область знаний и как это влияет на формат хранения - но это база технических изделий, со всеми возможными параметрами, от авторов чертежа до объектов где эти изделия могут применяться. Хранятся разумеется, только важные параметры (которые целесообразно/нужно хранить).
Касательно объёма памяти и размеров БД. Пока всё работает и меня всё устраивает, но для примера, мы можем предположить что объём БД в 10 раз больше объёма памяти и отталкиваться от этого при расчётах.
Набор полей - это динамические атрибуты объектов, там потенциально может быть что угодно, от среднеарифметической доходов и количества лап до фамилии прадедушки в 8-м поколении. Спрогнозировать "что будет завтра и в каком количестве?" к сожалению, невозможно.
Объём данных - примерно 1.5 млн. записей (уже/сейчас), к каждой из которых привязано в среднем 20 значений (т.е. будет 30млн. записей значений), из них на данный момент: 70% - целые числа, 20% строки, 10% дробные (примерно).
Илья Гребеньков: мне кажется, условия там похожие. Если кто-то модифицирует или включает Ваш исходный код в свой проект, он обязан предоставить исходники в конечном (измененном) виде, по первому запросу. Я конечно не могу ручаться за точность этой информации, но мне кажется это наиболее подходящая по смыслу лицензия. Именно благодаря подобной политике появилась такая ОС (сборка) как CentOS, являющаяся по сути пересобранным вариантом RedHat'а (которая в свою очередь является коммерческим проектом и продаётся) из исходников
sim3x: количество полей заранее неизвестно, к тому же, их может быть довольно большое кол-во, иногда >1000. Плюс, значение может выступать и в роли числа и в роли строки (если это исключительно цифры), в зависимости от условий поиска. По этой причине, "нормализовать" данные выше описанным способом - не представляется возможным.
Но одно условие всегда соблюдается на 100% - это одномерный, простой массив.
Не совсем понимаю, каким образом "это" можно нормализовать... если очень сильно абстрагировать ситуацию, то она будет выглядеть так: от пользователя приходит набор данных (массив, одномерный) либо строк, либо чисел. В зависимости от условий/ситуации, мы должны либо выбирать все записи которые содержат какой-то текст, либо все записи которые попадают в некоторый диапазон, например >=10 AND <= 100, все эти условия действительны применительно к элементу массива (одному, любому элементу одномерного массива).
Структура данных стабильна - это одномерный строково-числовой массив, в виду чего он храниться в формате VARCHAR.
Мне кажется идея использовать JSON-поля, ничем по своей сути не отличается от идеи использования массивов. Операторов сравнения, или LIKE для JSON'а в документации, я не нашел.
По первой ссылке я нашел только информацию как создать процедуру/функцию, ничего на тему того, какую логическую роль эта самая процедура или функция должна выполнять в задаче частичного приведения (по мере возможности) массива строк к массиву целых - я там не нашел.
sim3x: Про индексацию прочитал, индексируются, отлично!
Остался только один вопрос пожалуй, по этой же теме. Есть JSON-массив, сохраненный в поле (JSONB), с такими для примера значениями: ["a", "b", 10]. Как мне выбрать все записи, у которых есть элемент JSON-массива (сохраненного в JSONB поле) который >= 10 ?
И если не сложно, опишите пожалуйста более подробно, что имеется в виду под фразой "процедура"? Т.е. что она в общей сложности должна делать (логика её работы)?
SELECT DATE_SUB(NOW(),INTERVAL 30 DAY) AS new_date-- это просто для теста (что бы Вы видели, что за значение получается)-- я не проверял, но думаю должно работать... Если у Вас столбец с просто датой, а не с дата-временем, то будет примерно так:
хотя и предыдущий вариант тоже сработает скорее всего, в MySQL по моему дата автоматиеские приводится к дате-времени, при подобных условиях