Найти - Пользователи
Полная версия: Запрос к базе данных (поиск по дате)
Начало » Python для новичков » Запрос к базе данных (поиск по дате)
1 2 3
Rodegast
> Сначала надо посмотреть; может, оно просто так работать будет.

Вот по этому я и написал что циклом лучше чем то что у тебя (“Explicit is better than implicit.” ведь правда…).

> Там вообще, может, другой подход нужен изначально.

Я этот подход в своём первом сообщении привёл.
py.user.next
Rodegast
Я этот подход в своём первом сообщении привёл.
Ты привязался к PosgreSQL, будто это стандарт какой-то. А это не так. Стоит этой фигне попасть на комп, где нет PostgreSQL, потому что он стоит, например, там $100 в месяц, твой код сломается. Переписывать его времени не будет, а задействовать его будет невозможно.

Rodegast
Вот по этому я и написал что циклом лучше чем то что у тебя
Ну ты код приведи и сразу станет видно, что ты не шаришь. Разговоры разговаривать на форуме сисадминов будешь.
Rodegast
> Стоит этой фигне попасть на комп, где нет PostgreSQL, потому что он стоит, например, там $100 в месяц, твой код сломается.

Не переживай, PostgreSQL бесплатный

> Ну ты код приведи и сразу станет видно, что ты не шаришь.

Что за код я должен привести? Под алхимию? Так я ей не пользуюсь, а нормальный запрос я уже написал
py.user.next
Rodegast
Не переживай, PostgreSQL бесплатный
Не, как хостинг решит, так и будет. Видимо, ты не сталкивался с такими случаями, когда хостинг влазит в политику установки приложений на нём.
Rodegast
> Не, как хостинг решит, так и будет. Видимо, ты не сталкивался с такими случаями, когда хостинг влазит в политику установки приложений на нём.

Я с хостингами уже лет 10 как не сталкивался. В любом случае эта проблема решается заменой хостинга на более адекватный.

> вот завтра поступит команда “перевести это с PostgreSQL на MySQL или там MSSQL”, вот ты что делать будешь? переписывать сотни этих выборок с одного SQL-диалекта на другой или всё-таки ты используешь такую вот ORM типа Алхимии

Проблема перехода с одних источников данных на другие не решается при помощи использования тех или иных библиотек, а с помощью правильной архитектуры. Вот поступит тебе команда “получать данные не из БД, а из API” и что ты будешь делать? Я так думаю что всё переписывать А все из за того что используя ORM ты не можешь абстрагироваться от источника данных.

> А все вот эти анализы должны выполняться снаружи базы данных.

А как же таблицы с миллионами строк?

> Во-вторых, из SQL-кода ты столько не выжмешь, сколько из питон-кода. … они являются просто процедурами в какой-то там древней парадигме, которая особо ничего не даёт.

Если ты в чём то не разбираешься, то лучше промолчи … за умного сойдешь
ZerG
Тебе нужно просто сформировать
запрос к БД делать выборку контактов по дельте (today, delta) не учитывая год, а только месяц и день
py.user.next
Rodegast
Я с хостингами уже лет 10 как не сталкивался. В любом случае эта проблема решается заменой хостинга на более адекватный.
Не, это делается по-другому. Ты делаешь абстрактный исполнитель, который абстрактно работает с абстрактной базой данных. Ты не делаешь PostgreSQL, потому что она может не сработать где-то в какой-то установке, а ты PostgreSQL подключаешь к этому абстрактному исполнителю и оно работает, пока это разрешено и получается. Как только PostgreSQL надо сменить, ты его меняешь спокойно и всё, переливаешь данные в другую хрень, которая там понадобится. Просто подключаешь другую СУБД к своему абстрактному исполнителю. Так как он абстрактный, то он абстрактно работает с абстрактной базой данных через абстрактную СУБД. Поэтому всё это возможно делать. Понимаешь, да, что такое полиморфизм? Вот это полиморфизм. Благодаря этому устройству можно написать один код, который как-то определённо надёжно работает, но при этом натянуть его с самого начала на что угодно и иметь при этом возможность перенатянуть его в любое время на любую другую хрень любого вида и с любыми особенностями. Можно и с несколькими абсолютно разными базами данных сразу одновременно работать через один и тот же код, но ты пока маленький, чтобы такие вещи понимать и выстраивать в голове, у тебя пока только одна база данных и всё. То есть думать параллельными полиморфными структурами ты пока не умеешь.

А то, что ты предложил ему, - это “я предлагаю PostgreSQL”. Вот тебе сегодня её можно на хостинге, а завтра тебе говорят “а теперь давай $100 плати, мы передумали, она теперь не бесплатная у нас”. Ты хочешь уйти с хостинга, а у тебя там целая гора всякой хрени на этом хостинге, так просто не переведёшь это всё. И вот ты думаешь… а они же тоже не дураки, знают, что тебе предлагать. Они знают, что ты зависим от PostgreSQL, и они тебя спокойненько обрабатывают в связи с этим. А когда у тебя нет такой зависимости, они начинают тебя обрабатывать, а ты раз и переключился на другую фигню спокойно. Просто классы перенастроил и всё.

Для того и ORM эта нужна. Она вообще не привязана ни к чему.

Rodegast
В любом случае эта проблема решается заменой хостинга на более адекватный.
А если это уже самый адекватный? Неужели ты думаешь, что все себе выбирают наихудшие хостинги и сидят на них до посинения? Нет, бывает вот, что какая-то тупорылая хуйня начинает с тебя вдруг брать плату. Это в Slack'е так было. Было сначала всё нормально, а потом туда кто-то пришёл на работу и началась другая политика типа “мы о вас решили позаботиться типа, поэтому мы вам всё урежем сейчас и вы нам тогда заплатите, чтобы мы вам это обратно открыли”. Идиоты. Такое впечатление, что они наняли менеджера, который из какой-то конкурирующей фигни пришёл их специально замочить, просто разложить их в пыль. Что ни нововведение, то какая-то хуета вот такая. Изначально они себя позиционировали как заменитель электронной почты, прямо это как электронная почта, только лучше. Но это продержалось только два-три года всего, а потом началось такое, что это никакая не электронная почта даже близко. В электронную почту никакой дебил не может прийти с улицы и начать всю политику по всему Интернету менять. Она как раз останется неизменной. Вот в этом они просчитались. И поэтому нахуй пошли. Я на Discord сразу перешёл и перевёл всех. Сейчас про этот Slack даже не вспоминаю. А то вот они позиционировали себя чуть ли не новой эпохой Интернета. Ну обычные дебилоиды из разряда тех, которые Linux хотели платной сделать. Тоже кучка дебилов каких-то, которые нахуй никому не нужны. В итоге Linux бесплатная, а где они все?

Так что ты плохо себе представляешь, как эта вся поебень там работает. Могут тебе сказать, да вот PostgreSQL - это классно, конечно, хотелось бы, но вот у нас его нет, мы не можем его поставить, давай другое. И вот ты сталкиваешься с тем, что у тебя для PostgreSQL'а всё написано. И что ты будешь делать? Ну и всё, твоя прога не работает.

Я вот под Windows не пишу, хотя там то же самое возникает “а дай нам версию под Windows”. Но я-то знаю, что Linux всегда можно поставить, потому что? потому что она бесплатная. Её не надо покупать. Весь Интернет на ней работает, на её прогах, которые и на BSD портированы все напрямую. Так что в этом проблем нет, оно не может быть заблокировано в Интернете. Если там блокируют Linux, то там точно идиоты какие-то и с ними просто не надо работать.

А вот PostgreSQL - это да, вместо неё есть куча других СУБД и баз данных. И какая там будет, хер его знает. Поэтому от этого мы абстрагируемся. Защищаем программу от конкретных деталей.

Rodegast
Вот поступит тебе команда “получать данные не из БД, а из API” и что ты будешь делать?
А ты думаешь, у меня программа знает, что она из базы данных данные берёт? Она не знает, она берёт от интерфейсов что-то там, а куда они там прикреплены, она не в курсе.

Rodegast
А все из за того что используя ORM ты не можешь абстрагироваться от источника данных.
Не, к ORM'у прикреплен интерфейс. ORM - это просто исполнитель. Его можно заменить в любой момент на другой ORM. Для того эти интерфейсы-то и делаются. Ты общаешься с интерфейсами и всё, а куда они прикрепляются - сегодня туда, завтра сюда - ты не в курсе. Ничего не меняется в плане работы с ними.

Rodegast
А как же таблицы с миллионами строк?
В его случае оставляется всё, что он там наплодил. Ты говоришь “надо цикл какой-то там делать”, не надо ничего делать. Это минимальное изменение, чтобы ему всю хуйню не переписывать. Так-то да, надо смотреть, что он там вообще делает. Может, он неправильно вообще всё сделал.

Ты говоришь “а давайте ещё вот к этой всей хуйне неправильно ещё и PostgreSQL добавим”, а зачем? Чтобы ещё больше наворотить? Это не решение.

Rodegast
Если ты в чём то не разбираешься, то лучше промолчи
Ну вот как раз ты и не знаешь. Хотел бы что-нибудь сказать, а что тут скажешь, если у тебя элементарных знаний нет. Ты даже интерфейсы не освоил, не понимаешь, что это и зачем они нужны. Приходится вот тебе рассказывать тут. Книг-то ты всё равно не читаешь, они там все на английском. А по-русски таких книг не пишут, только доисторические.
Rodegast
> запрос к БД делать выборку контактов по дельте (today, delta) не учитывая год, а только месяц и день

http://python.su/forum/topic/43014/?page=1#post-228642

> Не, это делается по-другому …

Много букоф. Не читал.

> А если это уже самый адекватный …

Много букоф. Не читал.

> Ты говоришь “надо цикл какой-то там делать”, не надо ничего делать

Если после сообщения стоит смайлик “ ” или “ ”, то это значит что я просто прикалываюсь над тем что ты написал. Вроде не первый день на форуме, должен знать…

> А ты думаешь, у меня программа знает, что она из базы данных данные берёт …

Это всё твои понты. А что по факту? SQL - ты не знаешь. Может ты умеешь с ORM работать? Да нет, тоже не умеешь. romario82 даже не может нормально модель создать, но его решение (это то которое неизвестно как будет вести себя на стыке месяцев) на порядок лучше твоего бреда над которым я прикалывался. Из этого можно сделать вывод что у тебя нет опыта написания приложений которые активно взаимодействуют с БД.
py.user.next
Rodegast
Много букоф. Не читал.
Как раз поэтому ты ничего и не знаешь. Чтобы что-то знать, надо читать постоянно, причём всё читать и много. Сначала ты отмазки лепил, что английский такой плохой язык, что на нём вообще ничего читать не надо, и поэтому ты ничего не знаешь, что там на английском понаписали. А понаписали там много всего. Теперь и про русский тоже у тебя отмазка, что там много пишут слишком, это тяжело читать, поэтому читать только краткую информацию нужно, она типа самая умная. И куда хочешь прийти с вот этим вот настроем?

Ну вот такой у тебя барьер. Ты сам его укрепляешь. “Мне лень вот сегодня читать такую-то фигню” - это и есть укрепление.

Вот ты написал
Rodegast
SELECT
id, "name", surname, email, phone, birthday, "text"
FROM
contacts
WHERE
numrange(
(SELECT EXTRACT(DOY FROM CURRENT_DATE))
, (SELECT EXTRACT(DOY FROM CURRENT_DATE))+7
) @> EXTRACT(DOY FROM TIMESTAMP birthday)
Ты думаешь, это SQL? Все реляционные СУБД поддерживают язык SQL, но если ты вставишь это выражение в другую СУБД, то оно там не сработает. Почему? Потому что там SQL, а это не SQL.

Rodegast
Может ты умеешь с ORM работать?
Для тебя ORM - это тоже какой-то космос, а для меня нет. Ну у тебя там опять с английским проблемы. Где английский - всё, там для тебя дверь закрыта и всё. Какой-то там гуглопереводчик тебя не спасает, потому что гуглопереводчик нужен чисто для трали-вали, дайте мне пакет молока и не более того. В самих книжках на английском ошибки бывают, смысловые прям ошибки бывают. Иногда читаешь, написана какая-то ахинея по смыслу и тут понимаешь, что автор неправильно выразился. Можешь ему даже написать потом и он ответит потом “да, да, да, я пропёрся там”. С гуглопереводчиком - он сам тебе ошибок нагенерит, которых там и не было вообще. Так что об чём ты собрался поговорить, если ты его не знаешь?

Rodegast
romario82 даже не может нормально модель создать, но его решение (это то которое неизвестно как будет вести себя на стыке месяцев) на порядок лучше твоего бреда над которым я прикалывался.
Не, он запустит, оно срабоает, а твои бредни про единственное, что ты знаешь, где-то там перевёл через гуглопереводчик и книжку нашёл, тоже перевод, просто пройдёт мимо как не в тему сказанное. Никто не заметит.

Rodegast
Из этого можно сделать вывод что у тебя нет опыта написания приложений которые активно взаимодействуют с БД.
У тебя для выводов аппарата нет.

Вот у него одна база
SQLite
https://python.su/forum/topic/28238/
Вот у него вторая база
MySQL
https://python.su/forum/topic/35320/

Дальше он поднялся и стал использовать ORM. Слишком много баз и все надо изучать, поэтому надо взять что-то попроще, единообразное и вот эту штуку подключать к любым базам, чтобы не изучать их все.

А вот твои выводы, насчёт того, что оно упадёт, на чём основаны? На размышлениях, сформированных гуглопереводчиком? Я же говорю, у тебя нет аппарата для выводов там каких-то. Делать-то ты их можешь, но это выводы Наполеона из шестой палаты.
py.user.next
Rodegast
SELECT
id, "name", surname, email, phone, birthday, "text"
FROM
contacts
WHERE
numrange(
(SELECT EXTRACT(DOY FROM CURRENT_DATE))
, (SELECT EXTRACT(DOY FROM CURRENT_DATE))+7
) @> EXTRACT(DOY FROM TIMESTAMP birthday)
Я вот тут присмотрелся к твоему коду.
А что будет, если человек родился 1 марта, а год сейчас високосный и дата 22 февраля?
А что будет, если человек родился 1 января и сейчас 25 декабря?

postgresql. docs. extract
Вот они там пишут
The extract function returns values of type numeric.
То есть оно не будет перекатываться через границу года.

Не знаю, тебе надо вводить практику угарания над собственным кодом, а то она у тебя что-то не практикуется, а зря. Это школьные алгоритмы и вот ты их не вывозишь. Великий магистр
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB