Новый баз данных тред, теперь с альфа-версией шапки.
Здесь мы: - Негодуем, почему шапка - говно, и предлагаем коллективному ОПу идеи, как её улучшить. - Разбираемся, почему PostgreSQL - не Oracle - Пытаемся понять, зачем нужен Тырпрайс, если есть бесплатный опенсурс - Обсуждаем, какие новые тенденции хранения данных появляются в современном цифровом обеществе - Решаем всем тредом лабы для заплутавших студентов и задачки с sql-ex для тех, у кого завтра ПЕРВОЕ собеседование - Анализируем, как работает поиск вконтакте - И просто хорошо проводим время, обсирая чужой код, не раскрывая, как писать правильно
Литература: - Прибыл Фейерштейн. Oracle PL/SQL. Для профессионалов - если уметь исказть, можно найти бесплатно без СМС и на русском. - Алан Бьюли. Изучаем SQL. - про MySQL, тоже легко находится. Довольно старая, но базовые вещи не сильно меняются. - К. Дж. Дейт. Введение в системы баз данных - талмуд на овер 1000 страниц. - Томас Кайт. Oracle для профессионалов - тоже талмуд.
Q: Что лучше, SQL или NoSQL? A: Как обычно, зависит от задач. Нужна любой ценой скорость - бери NoSQL, нужна согласованность данных - SQL. У всего свои плюсы и минусы, и в обозримом будущем ни один подход не заменит другой полностью.
Q: Вопросы с лабами и задачками A: Смело спрашивай, с вероятностью больше 50% ответят, но могут и обоссать. на Дваче все твои друзья
Уже больше двух лет пытаюсь начать задания на sql-ex.ru Каждый раз когда перехожу по ссылке даже если ссылка работала у человека чье задание пытаюсь разобрать у меня показывает пикрил Что я делаю не так?
>>1869688 С MS SQL ты по определению должен будешь взаимодействовать с пачокй МСовского софта включая MS Windows Server, MSQL Server (Углубленно мочь в HA и DR) + MSQL Server Managment Studio (Углублённо мочь T-SQL), плюс ориентироваться в Азурных сервисах С ораклом тоже самое, только азур вместо редшифта и дальше пак маст хев аналогичного софта
Мочь в программирование ориентируясь в паттернах тоже нужно, как и уметь CDшить хотя бы БД
Конкретно эти две бд еще та анальная галера на любителя мимо на диване где-то прочитал в интернете
Аноны, посоветуйте, плиз, нубу DBMS по юз-кейсам. В одну таблицу (коллекцию) в базе каждый месяц будет добавляться по несколько десятков тысяч записей (примерно 350к за год). Нужно иметь возможность организовать пагинацию по этим записям с фильтрацией по критериям (полнотекстовый поиск по нескольким полям), сортировкой (дата создания или другое поле с числом) и быстрым доступом к произвольным страницам. Записи после добавления в базу почти наверняка изменяться не будут. Как фронт-энд макакен я сразу стал читать про монгу. Но, чем больше я про неё узнаю, тем больше у меня складывается впечатление, что от неё нужно держаться подальше. В частности, с пагинацией у монги хреново - чем больше документов в коллекции, тем больше будет тормозить получение "дальних" страниц.
>>1870365 >Кей-валуе Очевидно ты туда даже не заглядывал. Это тебе не редис. Есть особенности моделирования реляционных данных, выбора праймари и сортинг ключей, аксесс паттернов, учёт ограничений на дёрганье партишенов. Динамо безусловно лучшее масштабируемое решение на рынке
>>1869616 (OP) >Q: Что лучше, SQL или NoSQL? >A: Как обычно, зависит от задач. Нужна любой ценой скорость - бери NoSQL, нужна согласованность данных - SQL.
ну тоись если тебе нужны ебанутые бредовые результаты, но быстро, то бери NoSQL
>>1870610 > если тебе нужны ебанутые бредовые результаты, > но быстро, > то бери NoSQL Всё же можно придумать несколько юзкейсов, когда частичная или полная потеря данных некритична. Какой-нибудь кеш на редисе, который будет in-memory, собирается заново при перезапуске сервера. Что-нибудь по-быстрому посчитать в какой-нибудь бигдате, используя БД как промежуточное хранилище расчётов без дальнейшего хранения. По-быстрому высрать продукт с коротким временем жизни и не требующим поддержки - это как языки с динамической типизацией, где можно по-быстрому получить хоть и хуёвый и нестабильный, но результат.
>>1870610 Ну для какой-нибудь синхронизации тудушки на нескольких мобилках самое то Когда у тебя один таск может расшариться с одного девайса на 2 других, на втором модифицироваться и на третьем удалиться будучи неподключенным к интернетам ты на склах адекватно это не реализуешь в принципе
Относительно недавно работаю в финтех области(больше уклоном в фин), думал подучить в свободное время sql, но глянул вакансии по ключевому слову sql - требуются одни программисты. Стоит ли вообще заморачиваться этим не прогерам?
>>1869616 (OP) Читал эту мангу, по базам не очень, математические поинтереснее. >>1869688 Нет, это грязное SQL-программирование на процедурных языках с элементами ООП, требующее знания возможностей базы далеко за пределами CRUD.
В частности pl/sql - это часто программирование ETL-операций на диалекте паскаля, реже написание хранимок скрывающих сложную структуру данных.
>>1870610 >ебанутые бредовые результаты Eventual consistency, которая, как правило, имеет место у NoSQL DBMS, на 100% подходит для записи всего, что происходит один раз: история изменений цен на акции/курсы валют, история финансовых операций, история поведения пользователя и т.п.. Т. е. применений у NoSQL не так уж и мало. Потом конкретно у DynamoDB есть возможность делать strongly consistent reads - операции чтения, гарантированно возвращающие последнее значение полей записи в рамках одной зоны. В зонах, как правило, несколько локаций, и неважно, из какой локации писали в базу/читают из базы.
>>1873100 Профессия так и называется SQL Engineer Но очевидно по своей узкой специализации на джуна нужны знания на уровне знаний лоу сениора веб-макакена
Допустим я хочу что бы у меня искало по двум полям, но максимально быстро при этом.
SELECT x FROM clients WHERE zip=123 AND address='bolshoy text long search'
У меня zip чисельное да еще и индекс, но все равно выглядит так как будто он проверяет и address в том числе при каждом ебучем запросе. Я хочу что бы он чекнул zip - если нихуя не нашел то и некст поиск. Как это организорвать?
С чего я взял что поиск по адресу выполняется даже если провалился поиск по зипу? Потому что запросы вида WHERE (zip=123) AND ((address='bolshoy text long search') OR (address=' eshe bolshoy text long search') OR (address='bolshoy text long search') OR (address=' eshe bolshoy text long search')) всегда выполняются минимум 0.1 секунду
в то время как запрос без OR простой вида: WHERE zip=123 AND address='bolshoy text long search' может выполняться за 0.0002сек
>>1873311 а хуй его знает, почитай про 'Partial Index', сверху можно докинуть индекс на контролькую сумму строки (чтобы не по строкам индексировать/искать) и/или через any в массивах изъебнуться.
>>1873311 Порой сильно мешает эта хуйня, что порядок вычисления частей AND и OR в оракле не гарантирован, как в обычных языках программирования. Несколько раз проёбывался из-за того, что в правой части AND вызывается функция, которая кидает исключение, когда проверка в левой части даёт False, и если бы порядок гарантировался, исключение не кинулось бы никогда. Приходится из-за этого городить костыли с CASE WHEN.
Поясните, в чём отличие процедуры от функция, кроме того что функция не умеет INSERT/UPDATE, но может использоваться SELECT. В каких случаях нужно использовать первой, в каких второе офк кроме очевидных ситуаций которое попадают под ограничения?
А работал кто с MySql через MATLAB? И может кто подскажет: как я понимаю реляционная база данных-это большая такая таблица, которая имеет связи с другими таблицами. И есть ли какие-то конструкторы БД? Чтобы как-то графически сделать макет базы данных, а потом уже начать ее кодить/заполнять? Просто сейчас у меня на ум приходит сделать только две таблицы, но со временем БД надо будет расширять. И что лучше MySQL или MS SQL?
>>1875201 >как я понимаю реляционная база данных-это большая такая таблица Нет >И есть ли какие-то конструкторы БД? Какие-то гушные инструменты были, что то подобие конструктора >И что лучше MySQL или MS SQL? Если у тебя ничего сложного не будет, то бери что знаешь. Если будет - советую посмотреть в сторону постргреса
Анон, без sql не берут на работу. Можешь плез посоветовать самый быстрый способ набить такой минимум с которым не стыдно будет проходить собеседования?
>>1876114 Да это оба моих сообщения. Забыл что вчера примерно тоже писал. Ну вообще везде, где есть бэкенд. Пишу на пщ и петухоне. На каждом собесе спрашивают про sql. А я то хули, когда писал на питоне пользовался орм, а когда на го - были свои БДшеры.
>>1876109 Если идёшь на простого разраба, а не БДшника, то там и учить-то почти нечего, за пару недель можно управиться. Берёшь какой-нибудь хуёвый гайд ( https://metanit.com/sql ) или плейлист на ютубе. Смотришь, запоминаешь про создание/изменение таблиц, первичные/внешние ключи, инсерты, апдейты, делиты, селекты с типами джойнов и подзапросами. Прорешиваешь задачи ( https://www.sql-ex.ru ). Но прям все задрачивать не надо. Придумываешь схему БД для какого-нибудь книжного магазина или для социалочки, причём схема нормализована хотя бы до третьей нормальной формы. Пишешь соответствующий пет-проект без юзания ORM, тупо голыми запросами и смотря, как это принято делать в твоём языке. Всё, дальше опыт и stackoverflw.
Добрый вечер, аноны. Тут такое дело: за этот вузовский курс не было НИ ОДНОЙ, СУКА, ЛЕКЦИИ, а индивидуальное надо каким-то образом сделать. И вот, я начал с того, что нарисовал ИЛМ, в правильности которой очень сомневаюсь. Ибо тут, например, есть такой момент:
"Если не все компоненты имеются в наличии, то делает заявки на оптовые склады лекарств и фиксирует ФИО, телефон и адрес необслуженного покупателя, чтобы сообщить ему, когда доставят нужные компоненты."
Нужно ли, если говорить о таблице "Заказ", указывать в ней ИД пациента или нет (на мой взгляд, не стоит, т.к. оно уже было указано в "Рецепт" как внешний ключ, а ИД рецепта - как внешний ключ в "Заказе")?
И вообще, аноны, что скажете по поводу нормализации, связей между таблицами и т.п.? Сойдет или нет?
>>1869683 > В смысле область бд полудохлая? она не полудохлая, она, если говорить о программировании, давно и непоправимо сдохла. последние 20 лет никто, находясь в здравом уме, в новом проекте не запиливает бизнес-логику на уровне БД. осталось одно дикое легаси которое писали чуваки которым щас по 70 лет и прикладные околоадминистративные задачи.
>>1876844 Нет в заказе ненужен. Непонятно зачем таблица технология изготовления. Она должна находится не между складом, а отдельным линком либо за складом. Да и вобще лекарство это справочник, оно должно смотреть в рецепт, а технология за ней. Представь ситуацию когда лекарства нет на складе, но есть в рецепте. Вобщем погугли схему снежинка
Здарова пацаны Пилю бд для онлайн магазина (вообще впервые пилю бд) и вот возник вопрос. У меня есть таблица пользователей и таблица товаров. Теперь мне нужно зафигачить корзину. Я сделал таблицу со столбцами id - user_id - product_id - amount. Но погуглив, я увидел что некоторые аноны product_id и amount выносят в отдельную и связывают их. Зачем это нужно?
И еще сразу один вопрос. Я запускаю postgresql на локалхосте через докер, но уже второй раз бд сама по себе полностью удалилась. Точнее сама бд как бы есть, но таблиц в ней нет. Полагаю что это проиходит из-за того что я нажимаю кнопочку "обновить программы" в ubuntu и она обновляет либо psql либо docker. Я прав? И как избежать этого в дальнейшем
>>1877711 > Goods В магазине товары тоже не бесконечны, поэтому поле количества в ней тоже нужно. > OrderState Это может быть излишним, в большинстве СУБД есть поддержка enum-ок. > OrderLine Не понятно, зачем дублировать цену товара сюда. Разве что у тебя предполагаются какие-то наценки/комиссии, зависящие от времени,, но в таких случаях сумма скорее будет заранее подсчитана и храниться в таблице заказов, а не для каждой строки заказа отдельно.
>>1877714 Возможно, ты хранишь данные не в volume, а прямо в контейнере, и если контейнер удалится, данные пропадают и в новом контейнере не видны.
>>1869616 (OP) В таблице хранятся номера телефонов как varchar, нужно найти в таблице строку с подходящим номером, но вот незадача: в базе номера лежат номера в строгом формате: начинаются с 7 (русские номера), 11 знаков, никаких скобок и дефисов; а извне может придти любой телефон, скажем начинающийся с 8. Я могу отфильтровать на бэкенде всякие дефисы и скобки, но как делать эффективный запрос в базу, чтобы найти номер несмотря на то, что он будет начинаться не с 7?
>>1877902 Я тут в одном из прошлых тхредов предлагал использовать left вместо like, в итге был обоссан анонами. Вобщем like с индексмо работает довльоно быстро.
Во - первых, будешь делать пагинацию -- ни за что не используй limit/offset пагинацию (это когда у тебя SELECT FROM <table> WHERE <predicate> LIMIT n OFFSET m). Это очень плохая практика. Такой подход не масштабируется совсем. А когда к этому еще добавляют SELECT COUNT() FROM <table> WHERE <predicate> -- ето полный пиздец и приложение подохнет на первом же ляме записей (имеется ввиду такой запрос будет отрабатывать долго, и время будет только увеличиваться).
Используй seek-pagination (синоним keyset-pagination). Это немного сложнее, но разобраться можно. Загугли, там и прочитаешь аргументы против limit/offset пагинации и count() запросов.
Во - вторых, не используй LIKE запросы и тем более ILIKE (который регистро-независимый). Не, вообще можешь использовать, но только если у тебя есть триграммный индекс (в постгресе это модуль pg_trgm).
Это на мой взгляд главные подводные камни в нормальной пагинации.
Можно конечно еще дать советов, типа:
Если есть колонка, в которой хранится CLOB или BLOB (или просто тяжелые данные) и ты юзаешь ORM -- выноси это в отдельную таблицу и джойни с главной только по необходимости (когда пользователь кликнул на интересующую запись). Многие натыкаются при использовании ORM на такое, потому что эти фреймворки очень хорошо скрывают всю сложность.
Если у тебя есть фильтры, которые могут быть задействованы только вместе (скажем пользователь выбирает фильтр x, потом у него появляется возможность выбрать фильтр y и только после этого фильтр z) -- на такие вешай составной индекс (x, y, z). Порядок колонок в определении индекса важен. БД сможет юзать любую комбинацию (x), (x, y), (x, y, z). Но если ты отфильтруешь скажем только по y или только по z, или по y и z -- БД такой индекс не заюзает.
Для твоих целей монга не нужна совсем. 350 к записей в год при нормальном проектировании любая реляционка выдержит как нефиг делать (советую постгрес). И будет во много раз быстрее тормознутой монги.
>>1878484 И еще -- если схема БД хотя бы мало-мальски сложная (что часто бывает в кровавом тырпрайзе), скажем кол-во табличек становится больше 10 -- не пожалей и раскошелься на какой - нибудь софт, позволяющий визуально осмотреть ее. Потыкать на табличку, посмотреть на связи. Плюс менять ее очень просто и в конце она генерит тебе большой запрос, создающий твою БД. Это просто незаменимая штука в подобных делах. Не реклама, но сам я пользуюсь DbSchema.
Мигрировать с такой тулзой тоже проще намного. Например в DbSchema используется обычный xml для описания проекта и ты просто меняешь схему в нем (перетаскивая мышкой таблички и стрелочки), после чего любым diff-ом сравниваешь старый xml и новый и на основе него пишешь скрипт миграции.
>>1869752 если тебе нужен полнотекстовый поиск то я бы делал так - взял любую бд, постгрес например, который использовался в качестве хранения данных. и в дополнение к нему отдельно использовал бы полнотекстовый поиск, который строил бы индексы на основании данных в БД. индексы самой БД я бы не использовал, так как там начнутся сложности когда нужно бдет полнотекстовый поиск делать по нескольким таблицам сразу ну и архитектурно это смешение уровней приводящее к проблемам.
если говорить о реализации то например hibernate-search умеет такое из коробки. просто указываешь в аннотации все поля которые должны быть включены в индекс (в т.ч. коллекции или вложенные объекты) и он его тебе строит. Также есть возможность хранить данные в индексе, это приведет к тому что при поиске обращения к БД вообще не будет.
Звучит сложно но в реализации на самом деле все довольно просто и работает очень быстро.
можно и без хибера обойтись, взять любой движок для полнотекстового поиска и его использовать напрямую, например lucene, который в хибернейте используется по умолчанию.
база при этом вообще неважна, хоть дерби или h2 используй. она нужна только как хранилище данных если нужно будет поисковый индекс перестроить, как я уже говорил если все правильно настроить к ней запросов вообще не будет.
>>1878484 > Если у тебя есть фильтры, которые могут быть задействованы только вместе (скажем пользователь выбирает фильтр x, потом у него появляется возможность выбрать фильтр y и только после этого фильтр z)
это конечно хороший совет, но в реальности в больших приложениях все это нереально отследить. например сейчас в проекте над которым я работаю 150 сущностей (таблиц) у каждого из которых в среднем не меньше 10 полей. если отслеживать все комбинации полей в запросах то нужно будет строить несколько тысяч индексов, это нереально.
я сделал так - там где можно я использую внешний полнотекстовый поиск ( как описано выше) а в бд для каждой нетекстовой колонки создаю индекс. создание индексов автоматизировано. для особо тяжелых запросов, которые можно выловить при помощи логов субд, я создаю составные индексы вручную. это далеко не самый оптимальный сценарий но зато самый быстрый в разработке и сопровождении.
> Если есть колонка, в которой хранится CLOB или BLOB есть мнение что файлы в БД вообще хранить некошерно и для этого нужно использовать отдельное файловое хранилище
Аноны, есть Postgres, хочу запилить гео-распрелеленную систему. В сторону каких решений смотреть? Думаю над мульт мастером, нагуглил и попробовал Bucardo, но может анон знает что-то поинтересней?
Есть таблицы пицца и ингридиенты. У пиццы есть цена, которая складывается из ингридиентов. В таблице ингридиентов цена за каждый отдельный пункт установлена цена за 100 грамм.
Нужно сделать такую хуйню. У пиццы 5 ингридиент, ей надо взять 0.2 (20 грамм), 0.5, 1.2, 1.6, 2 из таблицы два разных игридиентов. Без понятия как такое провернуть.
>>1881058 Правильнее всего это делать на уровне приложения, подгрузив из базы данные об интгредиентах, а не SQL-запросов. А так можно изъёбнуться с каким-нибудь select sum ( 0.2 ⚹ (select price from ingedients where id = :intedient_id1) union 0.5 ⚹ (select price from ingedients where id = :intedient_id2) union 1.2 ⚹ (select price from ingedients where id = :intedient_id3) union 1.6 ⚹ (select price from ingedients where id = :intedient_id4) union 2 ⚹ (select price from ingedients where id = :intedient_id5) ) или хранимкой.
>>1877905 Так мне че-то самому интересно: регулярок как таковых же нет в sql? Там есть синтаксис для LIKE но он уебищный и во много уступает регуляркам. Как тот же номер телефона там найти?
>>1883108 >Как тот же номер телефона там найти sqlalchemy:
phone_pattern = '%{}%{}{}{}%{}{}{}%{}{}%{}{}'.format(*[i for i in phone]) query = sa.select([phone_table]).where(phone_table.c.phone.like(phone_pattern))
Сап аноны. Делаю бд для онлайн магазина. Каталог с возможностью добавления подкатегорий (за это отвечают столбцы parent_id и is_parent в caregories). Какие ошибки, что можно исправить? Буду благодарен за любую критику. P. S. бд пилю впервые
>>1883699 картинки к продуктам храню в файловой системе, для каждого продукта есть папка с id в качестве названия. Не нашел пока другого способа, что подскажете по этому поводу?
>>1883699 Норм. >>1883702 Лучше в файловой системе, скорее всего, будет работать быстрее, чем если хранить блобы в БД. Раздавать каким-нибудь нгинксом.
>>1877902 Если нет регулярок: TRANSLATE(phone, TRANSLATE(phone, '0123456789', ''), ''); Удаляешь всё что не является цифрой. Дальше можно первую 8 заменить на 7 и сделать из этого функциональный индекс или триггер-нормализатор телефонов при вставке в таблицу.
>>1877902 - >>1885664 Сорян, не совсем правильно прочитал. У тебя же получается где-то есть нормализация телефона и ты её можешь даже повторить.
Ну в общем для самой тупой базы это будет так: SELECT FROM tble WHERE phone = (CASE WHEN TRANSLATE(:phone, TRANSLATE(:phone, '0123456789', ''), '') LIKE "8%" AND LENGTH(TRANSLATE(:phone, TRANSLATE(:phone, '0123456789', ''), '')) = 11 THEN '7' || SUBSTRING(TRANSLATE(:phone, TRANSLATE(:phone, '0123456789', ''), ''), 2) ELSE TRANSLATE(:phone, TRANSLATE(:phone, '0123456789', ''), '') END)
Можно понадеяться на оптимизатор и чуть упростить: SELECT db. FROM tble AS db JOIN (SELECT TRANSLATE(:phone, TRANSLATE(:phone, '0123456789', ''), '') AS user_phone) AS sq ON db.phone = (CASE -- russian number WHEN sq.user_phone LIKE '8%' AND LENGTH(sq.user_phone) = 11 THEN '7' || SUBSTRING(sq.user_phone, 2) ELSE sq.user_phone END);
Но вообще лучше сделать нормализацию на бэкенде (и для каждой страны свою)
>>1869616 (OP) Подкиньте годноту для вката в проектирование баз данных. В частности, где досконально поясняется за модели данных, и за способы преобразования иерархической и сетевой модели данных в реляционные, и возможно - между собой. Как правильно спроектировать реляционную базу данных и как её нормализовать, и вот это вот всё.
У меня есть своя бд из трёх таблиц. В одной из таблиц хранятся email, который должен быть уникальным. Как написать в sql(sqlite) код так, чтобы при ошибке записи(email не уникален) он удалил только что внесённые данные в другие таблицы и вышел? Я так понял надо использовать savepoint и rollback, но у меня нихуя не работает
>>1886065 > при ошибке записи(email не уникален) он удалил только что внесённые данные в другие таблицы и вышел Транзакции называется. Начинаешь транзакцию через BEGIN или SAVEPOINT, выполняешь запросы, если один из запросов свалился с ошибкой, делаешь ROLLBACK, если дошли до конца без ошибок, делаешь COMMIT. Но это если ты вручную работаешь в консольке sqlite. Если ты делаешь это из какого-то приложения, у тебя там скорее всего будет механизм управления транзакциями, где ты в начале подключаешься к БД, запускаешь транзакцию вызовом нужной функции, делаешь запросы, в конце коммитишь или откатываешь. Важно, что там скорее всего будет включён auto-commit, его надо будет выключить.
>>1886090 Не, он же на непонятном. Только что погуглил переводы на русский, ссылка неактивна.
У меня тут парочка вопросов назрела. Возможно ли расширить таблицу, не добавляя поля к изначальной таблице, а создавая новую? Возможно ли создать таблицу с кучей полей, из кучи таблиц, где есть только ID и одно поле? То есть, имеет ли смысл, на каждое поле по таблице сделать, а потом увязать 1 к 1?
>>1886124 Не совсем понятно, о чём речь. > Возможно ли расширить таблицу, не добавляя поля к изначальной таблице, а создавая новую? Одним запросом это не сделать. Нужно явно создать новую таблицу так же, как создавалась старая таблица, затем скопировать в неё нужные данные из старой с помощью такого запроса: https://www.w3schools.com/sql/sql_insert_into_select.asp > Возможно ли создать таблицу с кучей полей, из кучи таблиц, где есть только ID и одно поле? Возможно, но с 1 к 1 обычно так не делают и хранят всё в одной таблице. Разве что для логического разделения сущностей, но это смотря как моделировать предметную область.
Триггеры ебучие, эксепшены, лупы-залупы прям в моём SQL.
Скажите, в чём вообще профит использовать их и в каких проектах оно нужно? Я это только в универе сдавал, а потом пошёл работать на web backend. Для каких вообще юзкейсов надо знать PL? Или это только для тех у кого Postgres не oracle?
>>1886314 У нас хранимые функции/процедуры часто юзаются в скриптах миграции, где простым DML заебёшься писать кучу типовых инсертов/апдейтов. Ещё есть OLAP-база, где в таких процедурах уже логика.
>>1869616 (OP) Связываются ли таблицы непосредственно внутри базы данных, или они связываются уже на уровне логики работы с базой - через запросы какие-то вроде JOIN-хуеин? Может ли быть внутри одной базы данных блок взаимосвязанных таблиц, которые не связаны с другими таблицами? Может ли быть несколько баз данных в одной базе данных? Можно ли сконвертировать всю файловую систему в базу данных?
>>1887058 И ещё вопрос, в догонку. Имеет ли смысл использовать вместо базы данных, кучу папок с названием таблиц, и кучу файлов в них, со значениями строк таблиц в JSON? Будет ли такая шняга работать шустрее, чем запросы к БД? Будет ли это проще, нежели пердолинг с сиквелом и CУБД?
>>1887058 > Связываются ли таблицы непосредственно внутри базы данных, > или они связываются уже на уровне логики работы с базой - через запросы какие-то вроде JOIN-хуеин? Да, связываются в виде констреинтов. Ты можешь создать его явно, либо он создастся неявно при указании foreign key, когда создаёшь таблицу. Но технически это не обязательно, констреинты нужны только для проверок, что такой ключ есть в таблице, на которую ссылаются (ссылочная целостность), а так их можно вообще не создавать и делать всё на уровне логики. > Может ли быть внутри одной базы данных блок взаимосвязанных таблиц, которые не связаны с другими таблицами? Да, хоть вообще никак таблицы не связывай, никаких ограничений на это нет. > Может ли быть несколько баз данных в одной базе данных? Нет. Зато есть понятие схем, их может быть в одной БД несколько. Правда, некоторые СУБД, например, mysql, эти понятия отождествляют. > Можно ли сконвертировать всю файловую систему в базу данных? Зачем? Теоретически можно представить файловую систему в виде реляционной модели и написать скрипт для наполнения такой БД. >>1887062 Только если у тебя там хранятся совсем простые данные, вроде настроек или чего-то ещё, чего немного и не жалко потерять. Для большего нельзя. Работать, скорее всего, для большинства задач будет медленнее. У тебя не будет ни транзакций, ни ссылочной целостности, ни индексов, ни оптимизации. Будет, конечно, проще, но это единственный плюс.
>>1887079 >Да, связываются в виде констреинтов. Ты можешь создать его явно, либо он создастся неявно при указании foreign key, когда создаёшь таблицу. >Но технически это не обязательно, констреинты нужны только для проверок, что такой ключ есть в таблице, >на которую ссылаются (ссылочная целостность), а так их можно вообще не создавать и делать всё на уровне логики. Ну, эта связь физически есть внутри базы, в том плане что задан ли где-то, в базе данных - тип связи (1 к 1, 1 ко многим, многие к 1, многие ко многим), или же эта связь задаётся на уровне запроса, а в базе данных - просто таблицы, и ID в качестве поля - в одной таблице, и ключевого поля с ID - в другой таблице?
>Да, хоть вообще никак таблицы не связывай, никаких ограничений на это нет. >Нет. Зато есть понятие схем, их может быть в одной БД несколько. Правда, некоторые СУБД, например, mysql, эти понятия отождествляют. Вот это хотел узнать. Ведь блок взаимосвязанных таблиц - это и есть база данных для какого-нибудь проекта (модель данных проекта). И в файле .db могут быть модели данных разных проектовы - что впрочем и понимается как разные "базы данных" для разных проектов (а не сам файл базы, ведь она может быть вообще в облаке, и может содержать множество никак не связаных друг с другом моделей данных).
> Можно ли сконвертировать всю файловую систему в базу данных? >Зачем? Теоретически можно представить файловую систему в виде реляционной модели и написать скрипт для наполнения такой БД. Я где-то слышал, что файловая система - это и есть база данных. Но это не точно. Походу да, и это иерархическая БД! В том плане, что дерево папок иерархично, ну там корневой каталог, и так далее - вложенные папки... Жесткие ссылки (hardlinks), а также ярлыки на файлы - позволяют из иерархической базы данных - сделать сетевую. То есть один файл, будучи размещён физически на одном на определённых секторах диска, может находится в разных папках, без дублирования данных, имея как-бы несколько взаимосвязей с этими папками. Но, и иерархическую, и сетевую модель данных, насколько я понимаю - можно свести к реляционной модели данных (правда не понимаю как?).
Так вот, если это возможно, и если базы данных пижже (ну там целостность, поиск, отсутствие дублирования, репликация, индексация, транзакции хуй знает чего, оптимизации), то почему бы не хранить данные - в реляционной базе данных, вместо файловой системы, с возможностью её подмонтировать как диск, и читать файлы из базы - BLOB'ами. И вместо бекапов - почему бы не делать репликацию базы данных с master на slave, для пущей отказоустойчивости? И если так, то почему бы не заебенить глобальную базу данных, где все файлы и их фрагменты, хранились бы в одном пиздатом облаке, имели бы кучу хэшей, и если они меняются - сохранялась бы отдельно, последовательность только лишь изменений их, без дублирования?
>>1887062 >>Имеет ли смысл использовать вместо базы данных, кучу папок с названием таблиц, и кучу файлов в них, со значениями строк таблиц в JSON? >Только если у тебя там хранятся совсем простые данные, вроде настроек или чего-то ещё, чего немного и не жалко потерять. >Для большего нельзя. Работать, скорее всего, для большинства задач будет медленнее. >У тебя не будет ни транзакций, ни ссылочной целостности, ни индексов, ни оптимизации. Будет, конечно, проще, но это единственный плюс. Аа, ну да. Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной, но это не значит что реляционную можно свести к иерархической (быть может к сетевой можно, но опять же - не знаю как). Если значение поля в строчке таблицы базы данных - будет содержать BLOB в 500 мегабайт, то и JSON-файл со строчкой такой таблицы, будет весить 500 метров, и чтобы проверить по условию значение другого поля в этой строчке, придётся грузить 500 метров... Если условие не выполнено - другой файл грузится, ещё 500 метров, короче пиздец, и пижже БД.
>>1887288 >Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной, >но это не значит что реляционную можно свести к иерархической (быть может к сетевой можно, но опять же - не знаю как). Если реляционную модель можно свести к сетевой, то и к иерархической, походу - но придётся дублировать эти ебучие данные.
Помогите плз задачку решить с sql-ex. Select(обучающий этап). Задача 125. Решаю на MS SQL Server
ЗАДАЧА Данные о продаваемых моделях и ценах (из таблиц Laptop, PC и Printer) объединить в одну таблицу LPP и создать в ней порядковую нумерацию (id) без пропусков и дубликатов. Считать, что модели внутри каждой из трёх таблиц упорядочены по возрастанию поля code. Единую нумерацию записей LPP сделать по следующему правилу: сначала идут первые модели из таблиц (Laptop, PC и Printer), потом последние модели, далее - вторые модели из таблиц, предпоследние и т.д. При исчерпании моделей определенного типа, нумеровать только оставшиеся модели других типов. Вывести: id, type, model и price. Тип модели type является строкой 'Laptop', 'PC' или 'Printer'.
МОЙ ЗАПРОС
with LPP as (select 'PC' as type, code, model, price from PC UNION ALL select 'Laptop', code, model, price from Laptop UNION ALL select 'Printer', code, model, price from Printer), AA as (select row_number() over(order by code desc, type) down_sort, row_number() over(order by code, type) up_sort, code, type, model, price from LPP)
select down_sort, up_sort, type, model, price from AA
Я короче сделал сортировку первый-второй-третий (up_sort) и последний-предпоследний (down_sort) Но вот как сделать их чередование я хз. Так что либо помогите допилить мое решение, либо тупо скиньте свое, в любом случае поклон вам в ноги
>>1887288 > в том плане что задан ли где-то, в базе данных - тип связи (1 к 1, 1 ко многим, многие к 1, многие ко многим) Нет, это на уровне логики/запроса. > Ведь блок взаимосвязанных таблиц - это и есть база данных для какого-нибудь проекта База данных - это более конкретная вещь, а не просто абстрактное понятие для набора таблиц. Это именно общее хранилище для разных сущностей, взаимосвязанных или нет. "Модели" может и разные, но база в любом случае одна. Например, "удалить базу данных" значит удалить все эти модели одновременно, которые якобы не связаны. Но это с практической точки зрения, принятой в терминологии SQL. Терминология может отличаться в других подходах. > Я где-то слышал, что файловая система - это и есть база данных. Но это не точно. Можно и единственный текстовый файл со списком чего-либо назвать базой данных, и в каком-то смысле это будет правильно. > Но, и иерархическую, и сетевую модель данных, насколько я понимаю - можно свести к реляционной модели данных (правда не понимаю как?). Например, есть такая таблица: id | parent_id | is_file | name id - просто айдишник, parent_id - ссылка на запись в этой же таблице, is_file - признак файла/каталога, name - название. И так можно строить иерархии. С сетевой моделью уже будет отдельная таблица связей многие-ко-многим. А содержимое файлов хранить в отдельной таблице, которая будет ссылаться на первую таблицу. > почему бы не хранить данные - в реляционной базе данных, вместо файловой системы Иногда БД - это лишний оверхед. В БД на первое место ставится надёжность, чтобы во что бы то ни стало не проебать данные, и пусть запрос ради этого хоть 100 лет выполняется. А если ты хочешь просто скачать пак с котиками, то тебе может быть всё равно, что процесс копирования остановится раз в много лет на 90%, проще скопировать заново либо вообще забить. > И если так, то почему бы не заебенить глобальную базу данных, где все файлы и их фрагменты, хранились бы в одном пиздатом облаке, Хотя бы из-за медленной скорости интернета по сравнению с жёстким диском. Есть шутка про то, что быстрее всего данные передаёт грузовик с жёсткими дисками. > Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной, но это не значит что реляционную можно свести к иерархической Да всё ко всему можно в предельном случае, лишь бы была программа, которая может это прочитать и представить в нужном виде.
>Например, есть такая таблица: id | parent_id | is_file | name >id - просто айдишник, parent_id - ссылка на запись в этой же таблице, >is_file - признак файла/каталога, name - название. >И так можно строить иерархии. >С сетевой моделью уже будет отдельная таблица связей многие-ко-многим. >А содержимое файлов хранить в отдельной таблице, которая будет ссылаться на первую таблицу. Коротко и ясно.
>> почему бы не хранить данные - в реляционной базе данных, вместо файловой системы >Иногда БД - это лишний оверхед. В БД на первое место ставится надёжность, >чтобы во что бы то ни стало не проебать данные, и пусть запрос ради этого хоть 100 лет выполняется. >А если ты хочешь просто скачать пак с котиками, то тебе может быть всё равно, >что процесс копирования остановится раз в много лет на 90%, проще скопировать заново либо вообще забить.
>> И если так, то почему бы не заебенить глобальную базу данных, >>где все файлы и их фрагменты, хранились бы в одном пиздатом облаке, >Хотя бы из-за медленной скорости интернета по сравнению с жёстким диском. >Есть шутка про то, что быстрее всего данные передаёт грузовик с жёсткими дисками.
У меня чё-то засела идея, один файл .db на весь раздел захуярить, с базой SQLite, и туда, короче - данные писать, и монтировать его как диск, как файловую систему. Но минусы, конечно же есть. Это bad-секторы. Значит надо два файла, походу, и репликацию заебенить. И ремап. Тупая, короче, идея.
>> Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной, >>но это не значит что реляционную можно свести к иерархической >Да всё ко всему можно в предельном случае, лишь бы была программа, которая может это прочитать и представить в нужном виде. Что ещё не заебенили? Мне что-ли нарукожопить эту хуйню?
>>1887350 > репликацию Оба файла могут попасть на bad-сектора, и если какой-нибудь заголовок похерится, куча данных проебётся. Не стал бы я хранить огромные бинарные файлы на дешёвом диске. > Что ещё не заебенили? Мне что-ли нарукожопить эту хуйню? Обычно нет смысла, делать из буханки автобус, вместо этого берут другой тип БД.
>>1887305 Чото ты херню каку-то делаешь. Через оконные функции попробуй. Делаешь row number(простой и desc) для каждой таблицы до обьеденения, потом по нему сортируешь, если нужен особый порядок сортировки, меняешь нумерацию на основе обоих столбов через CASE.
Твоё решение говно потому-что обьеденений будет явно больше трёх, ты чё для каждого будешь селект с юнионом корячить? Так что склеиваешь всё сразу, а потом уже дрочишся с сортировкой.
>>1886314 > Скажите, в чём вообще профит использовать их и в каких проектах оно нужно никакого профита нет, только легаси и административная хуйня типа миграции данных и распределения данных при партиционировании. за использование скриптов субд в бизнес-логике руки отрывают лет 20 уже как.
это остатки хайповой технологии 50-летней давности, когда была идея фикс писать приложения прямо в БД. сейчас код на плскл это то же самое что код на коболе.
>>1887062 >Имеет ли смысл использовать вместо базы данных, кучу папок с названием таблиц, и кучу файлов в них, со значениями строк таблиц в JSON? не имеет
> Будет ли такая шняга работать шустрее, чем запросы к БД? будет работать медленнее на порядок, а может и на три
> Будет ли это проще, нежели пердолинг с сиквелом и CУБД? будет сложнее на два порядка
>>1886314 Представь, что тебе нужно рассчитать много данных, примерно, 1 тер. Плюс должен быть пользователь который задаёт алгоритм расчёта руками через интерфейс. Как сделать это без хранимок?
>>1887575 > Ты питоном собрался 1 терабайт данных обрабатывать? ну если он поддерживает стрим данных/курсоры то можно и питоном.
> А субд какую юзать будешь? а в чем ты собрался терабайт хранить? постгрес, оракл, мсскл, дб2. какие еще есть варианты? можно на мускуле попробовать хз потянет ли.
>>1887577 >Грузить терабайт в ОЗУ, считать и сохранять обратно, так? ты задачу то опиши, что за обработка такая где нужно терабайт в память грузить и как с этим может справится субд?
>>1887584 > такая где нужно терабайт в память грузить Например, тебе нужно посчитать зп которая от продаж продаванов крупного ритейла. Можешь считать, что пользователь самостоятельно задаёт алгоритм расчёта. Для этого пользователю необходим интерфейс, поэтому это далеко не BI отчёт. >постгрес, оракл, мсскл Любой из, зависит от источника данных >как с этим может справится субд Вполне легко?
Если иерархическую и сетевую модель данных можно сконвертировать в реляционную, и наоборот, то можно ли нейросетевую модель данных представить в виде реляционной модели?!! Будет ли она фурычить также как фурычат мозги?
>>1887587 > Например, тебе нужно посчитать зп которая от продаж продаванов крупного ритейла. и зачем тебе для этого хранимка? это стандартнейший кейс для сервис-лэйера приложений, нафига его в уровень бд пихать?
>>1887587 > Вполне легко? ты не понимаешь вопроса. если тебе нужно обрабоать 1 тб данных алгоритмом, который требует грузить все данные в память, бд обосрется так же как и обычное приложение.
хранимка - это всего лишь набор SQL-запросов, которые ты просто можешь вызвать из приложения. и тут нет никаких отличий в скорости обработки данных или доступа к ним.
и нет ни одной разумной причины чтобы какую-либо бизнес-логику писать в хранимках. при этом логику в приложении ты можешь написать на нормальном языке, она легко изменяется, параметризуется и т.д. а в хранимках с этим большой пиздец.
>>1887849 > MVP > В мире стартапов и начинающего бизнеса денег нет. Есть только немного человеческого ресурса. Спека? Пффф... Это непозволительная роскошь. Тестеры? Пфф... Девопсы? Ну вы поняли. > Я храню все данные в файловой системе, как простой json файл. Это очень быстро, просто, и это отлично работает. > RAMа так много, что диск нужен лишь меньшинству
И это пишет джавист? Раз ему нужно срочно клепать дохуя неподдерживаемого говна, выбор жабы вызывает много вопросов. А почему тогда не пыха и js?
>>1869616 (OP) Аноны, подскажите, как лучше быть в такой ситуации. Я тут делаю бэк к одному приложению. Оно подключено к бд, которая будет меняться откуда-то ещё, т.е. не только изнутри приложения. И, значит, есть форма, где на фронте пользователь будет создавать новые объекты в одной мега-большой таблице. В этой таблице около 70 полей, из низ 30 ограничены вариантами из валидационных таблиц. Допустим, в одном поле выбирается из списка допустимых стран, в другом - какой-нибудь там тип кредита или опциона или ещё чего. Все эти типы могут со временем меняться, так что не захардкодить, а сами данные в базе могут меняться откуда-то ещё, извне моего приложения, так что и закэшировать нормально не выйдет. И вот я не хочу делать 30 селектов к базе, чтобы получить допустимые значения по этим валидационным таблицам. Как мне быть, какой лучше составить запрос? Или тут лучшим вариантом будет сделать какую-то вьюху на стороне базы, которая бы объединяла эти данные и обновляла автоматически, а я дергал уже её? Хотелось бы без этого обойтись
>>1887896 да это переводная статья десятилетней давности. написанная на хайпе всяких монгодб и прочих мусоросборников. доводы что там описаны обоссаны по сто раз уже.
>>1887932 > Но как я понял из статьи, БД и СУБД не нужны, потому что дохуя ебалы, и можно сделать всё проще, на низком уровне. нет. смысл статьи - если ваше говно умрет через 1 год то зачем заморачиваться?
вообще там почти над каждым предложением можно рофлить. технически это очень безграмотная статья, чувак не умеет и не понимает как работают бд, какие она использует алгоритмы и как это вообще все работает.
> Я храню все данные в файловой системе, как простой json файл. Это очень быстро, просто, и это отлично работает. > 100К активных пользователей — ровно столько я могу обслуживать с 1 ГБ RAM на виртуалке за 10 у.е. ололо блядь. и такой пиздеж всю дорогу
любая самая простая субд типа h2 просто порвет его json файлы в оперативке по производительности в клочья, когда потребуется сделать что-нибудь посерьезнее выборки пользователей по ключу. потому что тупо свалить все говно в оперативку - это не значит сделать выборку данных быстрее. чтобы оно быстро выбиралась нужно строить индексы, деревья и использовать продвинутые алгоритмы поиска. а если тупо массив в памяти держать и перебором его обходить каждый раз когда потребуются данные - это будет просто пиздец как медленно.
>>1888051 Ну вот с моего локального компа выходит по 0.068 секунд на один такой запрос. На проде всё будет быстрее, я думаю, раз в 10-20, так как всё в одном клауде находится. Но всё равно, это 30 запросов, мне кажется, что можно сделать как-то по-другому, как-то лучше.
>>1888058 > Но всё равно, это 30 запросов, мне кажется, что можно сделать как-то по-другому, как-то лучше.
ты можешь запросы юнионом объединять, но это тебе практически не прибавит скорости если база и сервак соеденены через локальную сеть, а геморроя в разработке добавит. это решение, в принципе, аналогично вьюхе которую ты хочешь создать.
еще решения:
1) настрой себе кеш и сбрасывай его раз в минуту например, судя по тому что ты описал это вполне приемлемо.
2) настрой триггеры на изменение какой-нибудь переменной в БД при обновлении данных. перед своими запросами проверяй ее и сбрасывай свой кеш тогда когда эта переменная изменилась.
3) сделай единую точку входа для получения и обновления данных и помести туда кеш.
>>1888223 > Т. е. ты считаешь, что лучше писать курсоры, которые запускают SQL? Ты уверен, что это будет красивей? найти задачу в которой тебе действительно потребуются курсоры - это еще надо постараться.
код который занимается обработкой данных должен быть в одном месте, и это аксимома разработки. если у тебя бизнеслогика размазана между сервером приложений и субд - это жопа. зачем тебе хранимка, если ты можешь весь код из нее просто взять и запустить в виде SQL-запроса?
Аноны, помогите, плиз, решить задачу, второй день не могу справиться. Хотя бы идею подкиньте. :'с
Задание: Вывести логины пользователей, у которых куплены ТОЛЬКО игры, выпущенные американцами в чётном году.
Мой вариант: select login from account join transactions on account.id = transactions.account_id join game on transactions.game_id = game.id join company on game.Developer = company.id where year(release_date)%2=0 group by login having max(case when country = 'USA' then 0 else 1 end) = 0
Коммент препода: Не ОК. У тебя, получается, выбираются все пользователи, у которых хотя бы одна игра попадает под условие. А нам надо, чтобы выводились только те пользователи, у которых ВСЕ игры на аккаунте сделаны в Америке и выпущены в четном году. Т.е., если у пользователя есть хотя бы одна игра, не подходящая под условие-он нам не подходит. Попробуй идти от обратного Ты ищешь игры, а не пользователей. Посмотри в сторону подзапроса.
>>1869616 (OP) >>1887316 >С сетевой моделью уже будет отдельная таблица связей многие-ко-многим. Являются ли связи - отдельными таблицами? Если да, то можно ли где-то просмотреть примеры таблиц, для связей: "1 к 1", "1 к M", "M к 1" и "M к N"? Как понять пикрил? Возможно ли реализовать связь "M к N" при помощи одних лишь таблиц, без этих вот связей, которые сверху соединяют таблицы?
Дело в том, что я всё-ещё смотрю на них, на эти связи, как на что-то неведомое, и реально соединяющее эти вот ебучие таблицы. Если этими связями, являются, просто, отдельные таблицы, с индексами то базара нет. Ведь как мы уже выяснили ITT, никаких связей в реляционной БД может не быть вовсе, там могут быть тупо таблицы. Но я всё ещё слабо представляю себе, как именно на них реализуется эти вот связи, неведомые.
>>1888295 >Являются ли связи - отдельными таблицами? Да, если это многие ко многим там появляется ещё одна таблица. >Возможно ли реализовать связь "M к N" при помощи одних лишь таблиц, без этих вот связей, которые сверху соединяют таблицы Да, связи между таблицами это всего-лишь ограничения на изменения данных в этих таблицах. >как именно на них реализуется эти вот связи Почитай про ключи и констрейнты.
>>1888304 > Более того - какая разница что ты дёргаешь - запросы или процедуры. Если код запросов повторяется, зачем плодить лишний код? какой лишний код? разница тут - в поддержке и разработке.
еще раз - код, реализующий бизнес-логику, должен быть в одном месте. в одном слое приложения, в одном классе. если ты реализуешь его в виде процедур или упаси боже триггеров, то ты размазываешь логику между несколькими слоями. ну да, это все будет работать, по первости то. но потом, через некоторое время, начнется пиздец. это во-первых.
во вторых - любая задача, отличающая ся от джойна трех таблиц реализорванная например на PL/SQL - это нечитаемый пиздец. это практически неподдерживаемый код, который пишет один раз а при необходимости изменений переписывается с нуля.
>>1888301 >Да, если это многие ко многим там появляется ещё одна таблица. Я вот попытался, мысленно, представить связи в виде таблиц, и воссоздать таблицы, обозначающие связь между таблицами.
То есть, как я понял, можно не связывать таблицы вообще, а просто создать эти вот таблицы-связи, и по ним уже смотреть как связаны таблицы с ключами A и B?
Ты говоришь, что появляется ещё одна таблица, для связи A и B? Нафига, если судя по всему, она содержит три поля, как и две предыдущие таблицы (1:M и M:1).
>Да, связи между таблицами это всего-лишь ограничения на изменения данных в этих таблицах. Это вся их суть? Я думал там глубже намного, тот же поиск связанных данных, например...
>Почитай про ключи и констрейнты. А где прочитать? Вижу в гугле что Foreign Key - это первичный ключ, ну id для каждой таблицы, который по определению должен быть всегда уникальным. А вот КАК ПРОИХОДИТ взаимосвязь этих Keys, при соединении таблиц в базе, - дремучий лес какой-то, походу связываются эти таблицы - какими-то неведомыми механизмами, проприетарными, копирастическими, и коммерчески-корпоративными, механизмами - код которых - закрыт, блядь. Если их, эти связи можно просто реализовать таблицами, то тогда другой базар, а так - магия какая-то, за которую надо нести копирастам бабала.
>>1888321 > Это вся их суть? Я думал там глубже намного, тот же поиск связанных данных, например... да, ты правильно говоришь, тот же постгрес сразу индексы на форенкеи строит
> за которую надо нести копирастам бабала. чет-тебя понесло не туда
>>1888342 Тогда такой вопрос: Возможно ли свести к реляционной модели все эти вот модели данных: https://ru.wikipedia.org/wiki/Модель_данных#Примеры или есть среди них какие-то несводимые, которые если не пижже реляционной модели, то какие-то особенные дохуя?
>>1888319 > реализующий бизнес-логику В таком случае нам нужно отталкиваться от определения бизнес логики. Вызов SQL кода питоном/жабой/php без процедур это бизнес логика? Если нет то да, нам нужно перенести логику в хранимки/триггеры. Аргумент от >PL/SQL - это нечитаемый пиздец не принимается так как в твоём случае от этого поста >>1887844 >хранимка - это всего лишь набор SQL-запросов, которые ты просто можешь вызвать из приложения мы должны будем также корректировать SQL код те же яйца только в профиль, который без динамики действительно рано или поздно станет нечитабельным говном. Да и pl/sql вполне легко читать, нужно лишь уметь это делать. Если же вызов SQL кода это не бизнес логика, то я с твоими предпосылками не согласен.
>>1888362 к реляционной модели можно свести практически все. более того, любую реляционную модель можно всегда свести к трем таблицам. только нахуя тебе все эти теоретические изъебства?
основная претензия к нереляционным базам заключается в том что в них очень хуёвая обработка связности и огромное дублирование данных, и огромные проблемы с их обновлением при большом объеме хранилища. а как только начинаются попытки решить эти проблемы то получаются велосипеды которые оракл изобрел еще полвека назад.
>>1888371 > В таком случае нам нужно отталкиваться от определения бизнес логики. ой вей. ну ок. есть данные. они где-то хранятся. а есть код, который эти данные читает, модифицирует и сохраняет. этот код и есть бизнес-логика.
когда ты в своем сервисе пишешь что-то вроде
connection.create.request("select count(*) from table")
это ок, потому что ты тут же и видишь что и как ты выбираешь а когда ты делаешь
connection.create.request("select calcMyGridSize() from dual")
это не ок, потому что ты не знаешь что это за calcMyGridSize и что он делает. в лучшем случае у тебя есть скрипт который эту функцию создал, но не факт что она с тех пор не изменнена парочкой альтеров и этот скрипт все еще актуален.
поэтому > Вызов SQL кода питоном/жабой/php без процедур это бизнес логика? это ок, потому что весь код, обрабатывающий твои данные у тебя перед глазами
> Да и pl/sql вполне легко читать, нужно лишь уметь это делать. ты на нем просто ничего не писал, поэтому так говоришь простейшая функция которая на нормальном языке занимает 3 строки на plsql занимает 30, а та, которая занимает 100 строк, на плскл занимает 3000
>>1888446 вот пожалуйста типичный пример функций на PL/SQL для обработки текстовых данных. даже не рискну вникать что тут написано, но уверен что на перле/питоне/яве это заняло бы строчек пять
>>1869616 (OP) >>1888418 >к реляционной модели можно свести практически все. >более того, любую реляционную модель можно всегда свести к трем таблицам. Вау! Чё реально, не более трех таблиц, у реляционной модели произвольной сложности? Как на пикрил, скажем.
>только нахуя тебе все эти теоретические изъебства? Интересно просто. Чисто академический интерес. Хотя, конечно, если изъёбств дохуя, то я думаю что мне это - нахуй не надо. Особенно, если это всё впроглено уже в какие-нибудь опен-сорцные(!) решеня - в частности, в сами механизмы ОПТИМИЗАЦИИ модели данных в БД. А если нет, то тогда уж... Надо бы впроглить, наверное - чтобы было как общественное достояние, и опенсорц! И вот как-раз для этого и надо бы изучить досконально, сами эти вот - изъебства ебучие, но не мне, а какому-нить более пряморукому кодеру, естественно. Хотя да, я, наверняка, могу начать это направление, задавая тупые вопросы, и ротируя матчасть ITT, а возможно даже и говнокод какой-то получится навелосипедить, ну а дальше уже, наверное, в разработку - подтянутся сообщество кодеров, и сделают что-то заебатое. Или не... Хз.
>основная претензия к нереляционным базам заключается в том >что в них очень хуёвая обработка связности и огромное дублирование данных, >и огромные проблемы с их обновлением при большом объеме хранилища. >а как только начинаются попытки решить эти проблемы то получаются велосипеды >которые оракл изобрел еще полвека назад. Я тут в SQLite на CSharp, чисто для себя, хочу вкатиться, потому что open-source, и никак не могу. Всё хожу вокруг да около, теории дохуя гляжу, и даже >К. Дж. Дейт. Введение в системы баз данных вот это качнул в DJVU (7-е издание)...
System.Data.SQLite.dll уже скомпилировал, получилось, но вот что дальше с этим делать - хуй знает. Пишут что это провайдер для ADO.NET, а там какой-то провайдер, блядь, который ещё и знать надо. Пытался качнуть примеры юзания этой базы - нашёл какую-то хуйню, а там sqlite3.dll внутри, а не System.Data.SQLite.dll . Пытался найти способ компиляции этого вот sqlite3.dll - нашёл какой-то код на С а не на шарпе, и пишут что надо через gcc конпелировать. А как - не ебу. Короче пиздец какой-то, на самом старте вката.
Нужна ли мне СУБД? Очевидно что да. А нахуя? Пушо она пижже. Нахуя она именно мне? Да хотя-бы, чтобы полный сорц сохранить, пушо опенсорц. Нахуя в частнсти? Да хотя-бы обычную регистрацию-авторизацию реализовать. Там же как минимум две взаимосвязанных таблицы должно быть: id | username| password_hash Ну и собственно userID | userDataВсякаяИтд
Или форму обратной связи: emails: >id|email Subjects: >id|Subject Messages: >id|fromEmailID|SubjectID|message|readed
Впереди куча планов для реализации различных проектов, от партнерских программ до сайтов знакомств, и везде нужна база данных. Почему C#? Да потому что опенсорц, блядь, а ещё потому что сервер портабельный получается, после конпеляции, и его, этот сервер, потом - на флешке его можно таскать! Почему SQLite - аналогично, полный опенсорц, ну и базу можно на флешке таскать, а не хранить хуй знает где, и использовать для её управления - хуй знает что.
Короче, мне наверное, надо что-то, желательно на русском, для вката, в эти вот все методы работы с базой и СУБД - SQLite, ну и теорию минимальную по СУБД, и SQL. Ну и минимальные, базовые знания к проектированию этих вот баз данных, разумеется, с возможностью их расширения, этих вот знаний, законспектированных.
>>1888473 > Вау! Чё реально, не более трех таблиц, у реляционной модели произвольной сложности? Как на пикрил, скажем. да. таблица объекты(аттрибуты), таблица их значений, и таблица для связи объектов между собой. к этому можно свести абсолютно любую реляционную модель.
Как будет выглядеть запрос в mysql, если при существующем name, в её колонку amound добавляется +1. Если не существует name, то добавить её, а amount оставить 1.
Загуглить не могу нормально, уже раз 15 попробовал.
>>1888446 >это не ок, потому что ты не знаешь что это за calcMyGridSize и что он делает. Ты не понял мою постановку задачи. Это не удивительно, скорее всего ты не работал в масштабных проектах и не знаешь зачем эти технологии нужны Ты не сможешь написать обработку, потом что у тебя пк сгорит, если ты в хэшмэпе будешь обрабатывать больше 200 гигов. Нахуя тебе делать селект, если от тебя необходим расчёт?
>>1888549 > Ты не сможешь написать обработку, потом что у тебя пк сгорит, если ты в хэшмэпе будешь обрабатывать больше 200 гигов. для этого есть бэтч лоадинг или курсоры или датастримы и тому подобное. но повторяю, ты покажи реально задачу, где нужно построчно пробегать по таблицам, в 99 процентах случаев это все спокойно заменяется групповыми и агрегатными запросами.
ты же сам написал >хранимка - это всего лишь набор SQL-запросов, которые ты просто можешь вызвать из приложения > мы должны будем также корректировать SQL код те же яйца только в профиль, который без динамики действительно рано или поздно станет нечитабельным говном ну да, так и нужно делать. побочный эффект - адовая обработка данных, пример которых на скриншотах выше, заменяется функциями на нормальном языке.
>>1888482 >таблица их значений Какая такая? Объект, это же не просто значение какое-то, у него может быть дохуя значений, а значит это таблица с переменным числом разноимённых полей что-ли?
Или имеется в виду что-то вроде: >|id|JSON| ?
Если да, то внутри JSON может быть ещё и BLOB'ы, аттачи - 500 мегабайтные...
Быть может, имелось в виду что-то вроде: >|id|property1|property2|property3|infinity...| куда можно ещё и писать, в поля property - данные разных типов?
Или, быть может: >id|property1Type1|property1Type2|...|property1TypeN|property2Type1|...|property2Type1|...|propertyMTypeN ? Чтобы по типу данные выбирались, а где тип не тот - там NUL? Тогда будет дохуя NULL'ей.
Сложно представить, в общем.
> и таблица для связи объектов между собой А эту как выглядит, интересно? Глядя на эту пикчу >>1888475 сдаётся мне, что объекты, они же могут быть связаны через их свойства, не? И ещё и разные типы связей могут быть, ну там (1:1, 1:M, M:1, M:N), тогда это вообще какая-то многомерная хуета получается, а не просто таблица.
Чёт прям жёсткое заявление. А насколько тру? Шо, даже простейшие триггеры хуйня? С другой стороны, это же неудобно. Если у тебя есть в коде миграции, то это надо код всего триггера через plain sql на up() закидывать и на drop() скидывать. Это ебаная срака и неудобно. Может есть какие-то инструменты, но я не знаю.
Я решил спросить потому, что возможно это в моих сайтегах на бляравеле и прочем говне такое не нужно, а в крупных проектах это обязательная ебель.
Точно легцы уже сто лет как?
>>1887572 А как эта ебень пишется и тестится? Какой воркфлоу? Миграции?
>>1888290 Хз, заработает ли. select login from account where id in ( select account_id from transactions where account_id not in ( select account_id from transactions where game_id in (select id from game where Developer not in (select id from company where country = 'USA') or mod(extract(year from Release_date), 2) = 1) ) ) Ищем сначала все игры, которые НЕ подходят - выпущены либо не американцами, либо в нечётных годах. Находим все транзакции, в которых покупались такие игры. Находим все аккаунты, к которым отностятся транзакции. Берём все аккаунты и исключаем из них аккаунты из неподходящими транзакциями. Берём логины по аккаунтам.
>>1889559 Попробуй позапускать отдельные подзапросы, вдруг на каком-то моменте я начинаю делать что-то не то. Тут надо сидеть и разбираться, сам сходу ошибку не смогу найти.
>>1889571 что-то не то судя по всему ниже этой строчки но это не точно select account_id from transactions where account_id not in Когда я убираю not, мне выдает список вообще всех логинов, то есть неподходящие видимо все. Но я могу ошибаться, только вкатываюсь в SQL и творю хуйню. Поковыряюсь ещё.
select login from account as usr inner join transaction as op on usr.id=op.id inner join game as gm on op.game_id=gm.id and gm.release_date % 2=0 inner join company as ct on gm.developer=company.id and company.country='America'
>>1889621 А ёбана, перечитал про препода, ебать он у тебя душила.
Тогда так:
with zalupa as
( select
acc.login, case when ct.country='America' and gm.release_date % 2=0 then 0 else 1 end as mark
from transaction as tr inner join game as gm on tr.game_id=gm.id inner join company as ct on gm.Developer=ct.id inner join account as acc on tr.account_id=acc.id )
select login,max(mark) as govno from zalupa group by login having mark=0
>>1889651 Спасибо, завтра попробую залупу Чем принципиально твой вариант отличается от моего? Я не доебываюсь, просто хочу понять, что именно преподу могло не понравиться в моём запросе, при том, что запрос выдавал нужные логины.
>>1889791 Тем и отличаются, что сделаны не так, как реляционные, а как-то по-другому. В реляционных у тебя таблицы, взаимосвязи через ключи, нормализация, транзакции, статическая схема. В NoSQL у тебя могут быть, например, хранилища JSON или XML, ключи-значения или даже графы. Для чего это нужно - не везде требуется такая надёжность ценой скорости, как в реляционных. Например, key-value кеш в ОЗУ. который не страшно проебать при перезапуске сервера. Или какие-нибудь JSON-ки, которые можно восстановить из бэкапа (в предположении, что делать это придётся очень редко), делаемого раз в день, а остальное вычислить заново.
>>1869616 (OP) Вопрос по связи 1к1. Как я понимаю, связь эта нужна, чтобы объединить две таблицы в одну, или добавить поле к таблице, не изменяя её, а создавая новую таблицу со значением нового поля. Так вот, если связать две таблицы по foreign key (первое поле "id" с автоинкрементом), то получается, что каждому "id" в первой таблице, соответствует этот же "id" во второй таблице, и никакой другой. Но связь 1 к 1 подразумевает то, что одному элементу соответствует ровно 1 элемент, и порядок их неважен. Например связь "idA" таблицы A (|idA|Afield1|...|) c "idB" таблицы B (|idB|Bfield1|...|): |idA|idB| |1|1| |2|2| |3|4|<-----3!==4 |4|3|<-----4!==3 ...
Так вот, вопрос собственно, как такую хуйню сделать? Нужно ли эту таблицу, (|idA|idB|) связывать снова 1к1 с таблицами A и B по полям |idA| и |idB|, или не? И ещё, должен ли у таблицы (|idA|idB|) быть дополнительный foreign key?
Ведь значения могут идти не по порядку, а скажем так: |idA|idB| |4|3|<-----4!==3 |1|1| |3|4|<-----3!==4 |2|2|
>>1889968 >соответствует этот же "id" во второй таблице, и никакой другой. Звучит так, как будто "и никакой другой таблице". Конечно же, имел в виду, что никакой другой "id", кроме того "id", который в первой таблице, равен "id"'у во второй таблице.
>>1889968 Чот ничо не понял. Зачем тебе третья таблица? Какой ещё порядок значений? В любом случае для 1 к 1 хватит двух таблиц. Связь 1 к 1 с двумя таблицами делается тупо хранением id первой таблицы во второй + констреинт, что во второй таблице id первой уникален, этим констреинтом можно гарантировать, что не будет больше одной записи, ссылающихся на одну и ту же запись в первой таблице (как 1 ко многим). Таблица1: - id - другие столбцы Таблица2: - id - таблица1_id -> таблица1.id UNIQUE - другие столбцы
>>1889683 Нужны два условия и год и игра. У тебя фильтр where применяется ко всему запросу.
Хотя у меня подозрение, что твой препод просто ебанный дед,которому нужно чтоб решили по евонному, через подзапрос. Но как известно любую задачу можно решить двумя способами, либо через подзапрос, либо джоинами.
>>1869616 (OP) Котаны, у меня есть доступ на удаленный сервак, я могу там подключаться к местной БД (postgresql) и читать оттуда данные, но мой юзер не имеет права ничего создавать, редактировать или запускать на том серваке. Я пытался выгрузить все данные из одной таблицы, но окно терминала наебнулось и попросту не захотело выводить мне результат (не может отформатировать или хрен его знает что), как мне вывести этот результат куда-то, где я смогу гарантированного его просмотреть? файлы там создавать я не могу
>>1888482 >> Вау! Чё реально, не более трех таблиц, у реляционной модели произвольной сложности? Как на пикрил, скажем. >да. таблица объекты(аттрибуты), >таблица их значений, >и таблица для связи объектов между собой. >к этому можно свести абсолютно любую реляционную модель. Есть где-то наглядный пример, ну или можете ли наварганить по быстрячку, чтобы очевидно было как третью таблицу строить, ну и первую тоже. Может если прохавать это, то можно будет сразу оптимизированные модели данных строить, и базы данных на них уже делать, оптимизированные?
>>1869616 (OP) >Есть где-то наглядный пример, ну или можете ли наварганить по быстрячку, Я сам впервые об этом услышал, это прикольно, но, вроде, элементарно, сделай сам.
>>1891143 > Может если прохавать это, чтобы прохавать это нужно нормальную книжку прочитать где написано про нормализацию.
> наварганить по быстрячку, как-то так OBJECTS(ID, TITLE) VALUES(OBJECT_ID,VALUE) OBJECT_TO_OBJECT(OBJ1_ID, OBJ2_ID)
> то можно будет сразу оптимизированные модели данных строить, и базы данных на них уже делать, оптимизированные? наоборот, оптимизация (в плане скорости доступа) подразумевает нарушение нормальных форм. почему монга быстрая? потому что данные в ней ненормализованы вообще. например: есть страница с сообщениями, у каждого сообщения есть автор, у каждого автора есть ник в системе, идентификатор, дата рождения и т.д.
монга хранит это как огромный JSON, и информация об авторе будет храниться в нем столько раз сколько сообщений он оставил, даже если на 100 постов всего один автор, то информация о нем хранится сто раз.
это очень быстро читается - один запрос к базе и ты выгрузил сразу всю информацию о странице и хуйнул ее на рендер.
но попробуй теперь изменить информацию о пользователе, например его ник, и тебе придется пересохранять все страницы со всеми сообщениями где он отметился. ну и транзакционность (а точнее ее отсутствие) тоже отдельная тема.
даже индексы, это с точки зрения теории нарушение нормализации, так как в них хранится информация о данных из таблицы, т.е. происходит их дублирование. они нужны чтобы ускорить доступ к данным но создают проблемы при их сохранении/обновлении.
но индексы - это приемлемо и затраты на их перестройку с лихвой покрываются их преимуществами. а вот хранить всю инфу в виде JSON - это в большинстве случаев неприемлемо и как только монга разрастается до неприличных размеров с нее мигрируют например на постгрес (где впрочем тоже есть поддержка жсон, так что даже скрипты для миграции под это дело есть готовые)
короче секрет успешной БД - это грамотное нарушение нормализации
> Котаны, у меня есть доступ на удаленный сервак, а доступ через что? если есть возможность пробрось порты через путти например и подключайся на своей локальной машине через pgadmin или через любую иде к котрой привык.
>>1893936 У тебя же не может быть возраст 99999999999, вот и ограничиваешь, сколько цифр у тебя максимум в числе. Ну а для char аналогично указываешь, сколько символов в строке максимум. Char же отличается от varchar тем, что char всегда физически занимает максимум места, даже если хранишь пустую строку, а varchar столько, сколько реально в нём хранится + 1 байт для признака конца строки.
>как-то так >OBJECTS(ID, TITLE) >VALUES(OBJECT_ID,VALUE) >OBJECT_TO_OBJECT(OBJ1_ID, OBJ2_ID)
Хм... Разве этого достаточно? Если взять за "объекты" - таблицы, а за "аттрибуты объектов" - столбцы этих таблиц, то глядя на эту картинку: >>1888475 , можно видеть, что объекты не просто связаны между собой, а связаны через различные, конкретно-указанные аттрибуты.
То есть, там должна быть не просто табличка для связи объектов (по аналогии - таблиц), но ещё и аттрибутов объектов (по аналогии - конкретных столбцов таблиц). А если ещё строки в таблицах связаны, или конкретные значения??? Тогда эта табличка всевоможных взаимосвязей, она, должна бы быть - пиздец какой многомерной, разве не?
>>1893936 В зависимости от типа СУБД varchar может быть неоптимально хранить или индексировать. Когда поле небольшое и фиксированной длины с ним проще выстроить эффективную работу.
>>1869616 (OP) В Постгрес если я удаляю таблицу (DROP TABLE) то мне потом отдельно надо будет удалить индексы к ней привязанные и CONSTRAINTS? Или они автоматом удалятся?
>>1869616 (OP) Пусть есть две таблицы: |idA|A| (int, text) |idB|B| (int, text) и пусть есть третья таблица для связи их: |id|idA|idB| (int, int, int) В ней - только id'ы, числами (INT).
Как с помощью SQL, показать таблицу |A|B| (text, text) ?
>>1894871 >>1894858 А можно как-то, без особого пердолинга, сделать так, чтобы эта таблица была таблицей в базе, и при вводе значений (A, B), чтобы автоматически добавлялась запись в первые две таблицы, и взаимосвязь этих записей - в третью таблицу?
А как доставать жсон-подобную инфу из sql бд? Просто вот допустим надо взять из таблицы С статус, он достается через джойн С с А. Также через джойн А и Б достается 1000 рядов допустим там заказчиков из таблицы Б через связь с заказом А.
В таком тупом примере получается, что уже надо два запроса. И что, потом их склеивать через язык программирования при формировании жсона? Джойн С с А и Б на похуях получается бредом, там этот статус будет один на весь заказ А. Полагается использовать всякие функции по возврату жсонов и массивов в постгресе чтобы одним запросом все нормально получить?
>>1894871 Бля, эта хуйня реально помогла. Тут, короче, взломанная база данных Пентагона, и какие-то таблицы ебучие, одна из них RocketsTraectories, содержит какие-то цифры непонятные, и приходится по двум разным таблицам Rockets и Traectories, сопоставлять всю эту хуйню вручную скролля эти грёбанные таблицы. Но два INNER JOIN'а, помогли сразу увидеть всё, как на ладони. Так охуенно теперь и быстро всё просматривается, все -все изменения, в реалтайме причём.
Но бля, как вот эту >>1894885 хуйню сделать, не пойму чё-то? Так и хочется, без пердолинга, просто ввести дополнительную запись, в таблицу RocketsTraectories, что-то вроде SQL-запроса: >ISERT INTO >INSERT INTO RocketsTraectories >VALUES > ("Булава-30", "Еллоустон") > ("Р-36М", "Тихий Океан") > ("РС-28", "Атлантический Океан") >; но, в этой грёбанной таблице очень многа цифар непонятных, и она просит цифры, в таблице Rockets - очень многабукаф, да и в таблице Traectories, тоже какие-то цифры и буквы... =( Вот копипаста их той всратой таблицы Traectories: >55°45'16.6"N 37°37'42.1"E >51°28'34.2"N 0°07'49.7"W Кто её писал, блядь? Как это разобрать?
Короче, надо годный SQL-запрос, чтобы при вводе данных в базу данных, в этой долбанной таблицы Traectories, всё правильно обновилось, и ещё в таблице Rockets, должны добавиться записи дополнительные, чтобы там появились новые значения, которые может вводить только сам админ базы данных этого вот Пентогона. И главное, чтобы без пердолинга!! А то я уже заибался с этими таблицами. Я ЩА ВОЛОСЫ НА ЖОПЕ СИБЕ ПАРВУ, ПАМААААААГИТИ!!!
>>1899337 Включаешь транзакцию и вставляешь в цикле, хуле. Потом в конце коммит. Через insert values (), (), () лучше, конечно, но это надо руками крафтить, если не лень.
>>1869616 (OP) Пусть есть табличка: |userID|user| |1|вася| |2|петя| |3|коля| |4|ася|
и пусть есть другая табличка: |id|idA1|idA2| |1|1|4| |2|3|1| |3|2|1| |4|2|4|
в которой, idA и idA2 - замкнуты на idA, связью 1 ко многим. Задача состоит в том, чтобы показать не ID'ы, а таблицу, вида: >user знает юзера |id|user|user2| |1|вася|ася| |2|коля|вася| |3|петя|вася| |4|петя|ася|
Как сделать эту таблицу на SQL? Пытался двумя INNER JOIN, но там две связи от полей idA, idB - на userID замыкаются, и оно ошибки бьёт.
>>1899384 Я сделал проще, тупо javascript'ом в цикле, сгенерировал в консоли браузера пиздатое полотнище из кучи команд, и в виде одного SQL-запроса, исполнил, и оно заполнилось. Ракеты пока не полетят, не ссыте. Я их просто нацелил.
Но что если их терабайт будет, этих запростов ебучих? Хотелось бы цикол, но ракет куча, а в сиквелайте у рекурсивных петель - синтаксис какой-то нипанятный.
>>1869616 (OP) Возможно ли связать таблицу, с таблицей, которой нет, в базе данных, но которая может быть образована из других, уже существующих, и взаимосвязанных таблиц?
народ посоветуйте годной литературы по ораклу именно по администрированию, как правильно разворачивать master slave роли настраивать бекапы, архивлоги и т.д.
>>1869616 (OP) Вкатываюсь в проектирование баз данных, со своим SQLite Expert Professional (x86) portable. Цель - заебенить криптобиржу. Пока что получился пикрил, хз можно ли оптимизировать это...
>>1900063 Я так понял, view, позволяет просмотреть таблички, которых нет, при помощи SQL-запросов. Погуглил чуток, нашёл возможность создать view'ы, и создал их, вставляя SQL-запросы туда. До этого, я хранил все SQL-запросы к базе - в отдельной таблице (|id(int)|Operation(text)|SQLRequest(text)|), как та несвязанная табличка, на пикрил.
Вопрос. А можно ли как-то СВЯЗАТЬ, другие несвязанные, или новые таблицы, с таблицами, генерируемыми этими вот view'aми?
>>1896508 Можете ниссать, это был прикол. А то какие-то шныри c пеленгатором, здесь, шманали вчера под дверями, один даже в окно пытался залезть, но сорвался и вышел в окно.
А другой с перепугу обосрался, и убежал, а перед тем ещё и, засранец, дверь говном обмазал, и написал: АНБ + ФБР = ♥
>>1901522 s of MySQL 8.0.17, the nonstandard FLOAT(M,D) and DOUBLE(M,D) syntax is deprecated and you should expect support for it to be removed in a future version of MySQL.
>>1896508 С такой постановкой задачей, просто иди нахуй. В твои стену текста вчитываться никто не будет. Если хочешь чтоб тебе помогли, формализуй задачу коротко.
>>1869616 (OP) Имеется таблица playlists с полями playlist_id, views и ещё какими-то. Нужно выбрать все записи для плейлистов с максимальным суммарным значением views. Написал запрос, который делает то, что мне нужно (пикрил), можно ли его упростить? Не делаю ли я в нём какой-то хуйни?
Анон, помоги! Чищу mariadb, удаляю по сотне тысяч записей каждые несколько минут, база худеет, но занятое место на диске только возрастает уже который день. Почему так и как это пофиксить?
>>1902633 На практике почти всегда вместо них юзают суррогатный ключ (id). Значения сразу нескольких колонок сопоставляют только в сложных джойнах и селектах.
Аноны, есть один сервис, с клиентами по всему миру, есть БД - Постгрес11. Я правильно понимаю, что единственный путь это мультимастер и установка нескольких серверов с БД в различных локациях и юзерами? Планирую для начала 3 таких локации и связать их звездой при помощи Bucardo.
>>1903868 OR выбирает записи, где выполняется хотя бы одно из условий (либо юзер из Лондона, либо ему 43 года, либо и то и то одновремено). AND - когда выполняются оба (юзер из Лондона и ему при этом 43 года)., то есть строка отсеивается, если хоть что-то не подошло.
>>1903902 начало доходить,те эти данные должны быть связаны допустим все Иваны из города Москва а если OR он вывалит и всех иванов(из всех городов) и всех москвичей ?
Как вставить функцию в шаблонизированную строку запроса? Поле created имеет тип timezone. Хочу привести исходные данные к этому типу с помощью postgre'вской функции TO_TIMESTAMP(). Как это сделать? INSERT INTO data.source(created, created_utc) VALUES($1, $2)
Если вставляю функцию непосредственно в значения, то такая ошибка: error: invalid input syntax for type timestamp with time zone: "TO_TIMESTAMP('1581569438')"
Если делаю так: INSERT INTO data.source(created, created_utc) VALUES(TO_TIMESTAMP('$1'), TO_TIMESTAMP('$2'))
То ошибка следующая: duplicate key value violates unique constraint "source_pkey"
Блядь, открыл первое (рейтинговое) упражнение на sql-ex и сразу охуел. Я только синтаксис прочел, а тут... Дима и Миша пользуются продуктами от одного и того же производителя. Тип Таниного принтера не такой, как у Вити, но признак "цветной или нет" - совпадает. Размер экрана Диминого ноутбука на 3 дюйма больше Олиного. Мишин ПК в 4 раза дороже Таниного принтера. Номера моделей Витиного принтера и Олиного ноутбука отличаются только третьим символом. У Костиного ПК скорость процессора, как у Мишиного ПК; объем жесткого диска, как у Диминого ноутбука; объем памяти, как у Олиного ноутбука, а цена - как у Витиного принтера. Вывести все возможные номера моделей Костиного ПК.
Помощи не прошу, просто хочу узнать может там как-то по нарастающей сложности задачки есть?
>>1905011 А, все, нашел что к чему. Интерфейс конечно там пиздец. Не сразу понял как выбирать сложность и номер заданий. Сначала значит надо пройти обучающий этап со всеми остальными, а потом уже если захочется рейтинговый.
Но вообще эта задача для меня выглядит пиздец какой зубодробительной, даже хз с какой стороны подойти. И кто-то же её придумал. Вот похоже знания и практика у людей мозги наизнанку выворачивает.
>>1894744 Хуй знает, почему 3 таблицы, в разных источниках по-разному это описывают, на лурке в статье про SQL вообще про 4 пишут. Но можно и одной обойтись, если забить на нормализацию: god_table: - table_name varchar not null - название таблицы - field_name varchar not null - название столбца - type_id shortint - id типа, в зависимости от него выбирается один из столбцов ниже - int_value integer null - инт - float_value float null - флоат - varchar_value varchar null - варчар - text_value text null - текст - blob_value blob null - блоб Работать с такими данными очень неудобно, но всё ещё возможно.
>MariaDB [users]> insert into users2020 -> values('Arthur','Moskow','49','[email protected]','2000','her2021'); ERROR 1136 (21S01): Column count doesn't match value count at row 1 MariaDB [users]> что не так?
>>1906912 Можно написать триггер с проверкой, триггер будет перед инсертом/апдейтом селектить существующие записи и проверять. Либо вообще вынести проверку на уровень самого приложения.
>>1907112 Уебанский синтаксис, а именно структура запросов, произвол в пихании куда попало ключевых слов лишь бы это было похоже на английский и все такое.
>>1907120 как в нормальных языках. например, если есть WHERE xxx IN ( arg1, arg2,...) то, блядь и делать WHERE xxx BEETWEN ( arg1, arg2) а не хуйню WHERE xxx BEETWEN arg1 AND arg2 как оно сделано Мало того, что меняется сигнатура по сути одной семантики - ограничения области, так еще и зачем-то вхуячено слово, которое и так уже используется как логическая операция в этом же, блять, языке, не говоря уже обо всех других То же самое еще в куче мест, например FROM-INTO и т.д.
>>1907119 >лишь бы это было похоже на английский В этом и была цель при разработке sql - чтобы он был максимально похож на естественный язык и на нём могли писать запросы простые людишки. Собственно, с этой задачей он более-менее справился.
>>1907133 Конечно, может. Но гораздо большую путаницу вносит как раз разный тип синтаксиса для по сути одного и того же. >>1907129 Естественный язык тем и плох для разработки ПО, что он сравнительно не строгий, и в нем все пихается плюс минус рандомно, лишь бы тупая нейросеть в кожаном мешке могла это понять, а если что переспросить. Плохо сделали, ящитаю.
>>1907141 >разный тип синтаксиса для по сути одного и того же Between - это бинарный оператор, а у IN операндов может быть больше (или меньше) двух, не помню как это одним термином называется. Это если с точки зрения программиста смотреть. С точки зрения нормиса всё ещё логичней - как в английском, так и в sql. >он сравнительно не строгий Так и есть. Но именно это и нужно было - чтобы "пользователи ПК" не переучивались мыслить как кодеры, а могли использовать знание своего языка для написания запросов (не знаю, насколько это в реальности нужно было, просто пару раз читал такое обоснование). То, что это стало стандартом - ну, так получилось, теперь мы с этим живём. Меня, например, конкретно синтаксис не очень сильно беспокоит в sql.
>>1907185 Это называется арностью операции. И вот как раз вызов операции в любом ЯП должен быть, если ЯП не уёбищный, организован типовым, унифицированным, образом. >Так и есть. Но именно Ну, какова бы история не была этого вопроса, суть не меняется: SQL как язык - уёбок. И все им пользуются только потому что он привычен, да и вообще маленький, типа, можно и выучить всё это нагромождение тупой хуйни наизусть, игнорирую то что это куча завязанных в узел костылей. Я что-то особо не знаю юзеров SQL, которые по совместительству не программисты на более божеских языках, и по сути поэтому можно заключить, что идея обосралась на корню.
>>1907122 > как в нормальных языках Скажи это дедам полвека назад. SQL - это легаси, с которым приходится жить. Давно придумали, все смирились с синтаксисом, написано дохуя кода и литературы с использованием SQL, это всё хрен выкинешь. Да и ради более модного синтаксиса никто и подавно этого делать не будет.
>>1907194 Sql - не ЯП же, значит можно. >все им пользуются только потому что он привычен Ага, а привычен потому, что все его учат. А учат, потому что привычен... >Я что-то особо не знаю юзеров SQL, которые по совместительству не программисты У нас есть аптечники, которые с БД работают на уровне простых select-insert-update.
>>1905932 В такой таблице дофига дублирующихся данных на каждую запись. как минимум, имя таблицы, повторяется, для каждой грёбанной записи... И ещё и null'ей куча, по всей таблице... И полей пиздец как много, ведь в ней поля для всех таблиц, которые могут иметь ещё и одно и то же имя.
Всё-же, мне кажется, что УНИВЕРСАЛЬНАЯ СХЕМА ИЗ ЧЕТЫРЕХ ТАБЛИЦ, ДЛЯ ЛЮБОЙ РЕЛЯЦИОННОЙ МОДЕЛИ ДАННЫХ (которую, я, кстати, тоже не могу ни по каким ключевым словам, блядь), мне кажется, что она будет более оптимальной. Интересно было бы взглянуть на неё, и уметь строить любые модели на базе этих вот четырех таблиц. Ведь, насколько я понял, такая таблица должна бы получаться - в результате оптимизации модели, и/или в результате нормализации данных или модели данных. Если так, то почему бы сразу не писать в нормальной, оптимальной, минимальной и удобной форме, вместо того чтобы связывать эти таблицы в ебические сети из нафиг не нужных сущностей, которые можно описать одной лишь табличкой - пропроще?
Вот в чём заключается, собственно, мой исследовательский интерес, в этом направлении. ____________________________________________________________________________________________ А пока, на SQLite, я тут, просто заебенил - простенький ToDo-list, в виде одной таблички: >id(integer),parentID(integer),ToDo(text),Description(text),Done(bool) Она, короче, позволяет - ветвить задачи в пиздатое дерево, при указании id родительской задачи - в parentID. Дальше, всю эту хуйню можно выводить как надо, уже через "View", более того, в view'e можно отображать только нерешённые задачи, фильтруя их по Done. Охуенно так получается, вся инфа о нерешённых задачах - в view'e, безо всяких цифр неведомых, и как только задача решена - отметил галочку, оно триггернулось, и пропала эта задача нахуй.
Может можно попижже как-то сделать, чтобы метки времени там были, чтобы эти задачи в последовательности сцеплять, чтобы они не в куче все выводились, а чтобы по порядку завершения цепочки задач... Может где-то есть уже готовые базы и модели данных для такой вот - "системы личной эффективности"?
Думаю, что база данных, идеальный вариант для подобной работы.
Также, была идея, сделать систему тегов для файлов... Три таблички (|id(int)|filepath (text)|), (|id(int)|tag(text)|Description|) ну и табличка (|id(int)|fileID(int)|tagID(int)|), для связи многие-ко-многим, между файлом и тегом. Чтобы видеть где прон, где жесткий прон, где очень жесткий прон, где супер-очень-жесткий прон, а где гипер-ультра-супер-мега-очень-жесткий-гипер-прон. Блобы решил не хранить в SQLite, а просто пути, а то хуятина эта раздуется пиздец, на весь жесткий диск, и слететь может нафиг.
Алсо, думаю MariaDB на флешку поставить, охуенно же опенсорц, к тому же меня ещё и прёт чёт-то ото всех этих баз данных.
>>1907211 >Sql - не ЯП С чего? то что он не тьюринг-полный, не значит что он не ЯП. По сути любой интерфейс между взаимодействующими сущностями это небольшой ЯП. >Ага, а привычен потому, что все его учат. А учат, потому что привычен... Нет, просто тонны легаси-дерьма вряд ли можно уже отвергнуть, к сожалению. Схожая ситуация есть с некоторыми аппаратными архитектурами, которые уёбищные, но слишком уж распространены. >работают на уровне простых select-insert-update. ради этих трех операций можно и аптечнику запомнить нормальный унифицированный синтаксис вызова. В итоге вышло, что ради того, чтоб одному аптечнику удобно было пользоваться 3% языка, 999 программистов мучаются с 100% тупого синтаксиса
>>1907223 > Если так, то почему бы сразу не писать в нормальной, оптимальной, минимальной и удобной форме, вместо того чтобы связывать эти таблицы в ебические сети из нафиг не нужных сущностей, которые можно описать одной лишь табличкой - пропроще? Сначала делаешь все в "минимальной и удобной форме". Затем понадобятся проверки, что в этих таблицах поверх таблиц записи содержат только указанные столбцы и только указанного типа. Для этого создаёшь ещё таблицы со схемой, пишешь много сложных триггеров и понимаешь, что заново изобрел таблицы с ебическими сетями сущностей, но лишним слоем абстракции.
>>1907223 >А пока, на SQLite, я тут, просто заебенил - простенький ToDo-list Такую ёбу лучше на JavaScript сделать, в виде одного JSON-объекта, плюс LocalStorage, так будет ещё и доступнее, в браузере. Там же нет множества таблиц связанных, просто одна табличка, которая может быть в один объект записана, и ещё один view, который может быть веб-мордой для объекта.
>>1907233 Мне почему-то кажется, что критерием оптимизации самой вот реляционной модели данных, является именно дублирование данных, в различных таблицах. Ведь, в пределе, как я понимаю, всё можно свести к банальным, взаимосвязанным между собой, спискам уникальных элементов - таблиц с одним полем, группируя их в таблицы по общему признаку. Ну а дальше уже, просто таблицы с числовыми ссылками на эти вот уникальные элементы списков. Каждое новое поле для таблицы с большим числом столбцов - это лишь новая таблица, свазанная с предыдущей - 1 к 1. И так, короче, куча таблиц получается, в каждой из которых по одному полю. В основном, это таблицы с цифрами, которые не занимают дофига памяти, а вот уникальные элементы, они просто в таблицах-списках, один раз записаны, и не дублируются нигде.
Так, мне видится, оптимизированная модель данных, но всё-же, ебическая куча таблиц - это не четыре таблицы, и не одна. Хотелось бы чё-то более универсальное, оптимальное, и конечно же - минимальное. Чтобы один лишь раз, нужные данные, в базу данных, забить, сделать их ридонли, как-то защитить, и не ебать уже мозг излишним их дублированием.
>>1907249 Не всё в реляционной модели сводится к оптимизации. Например, существование констреинтов не уменьшает дулбирование, но из этого не следует, что оно не нужно. То же самое с разделением сущностей и контролем типов на уровне СУБД.
>>1907249 Я мимопроходил и понимаю, что ты шизик, но желаю тебе счастливого Cartesian Explosion при джойне твоего оптимизированного говна.
Ну и вообще, твоё видение оптимизации странноватое. Что-то уровня демосценного байтоёбства. На деле важнее перфоманс, поэтому в реальных проектах часто прибегают к денормализации схемы БД.
>>1907360 На деле, всё просто. Вот есть схема данных, таблицы и их взаимосвязи. Если её с нуля строить, всё-как бы норм, пара таблиц, и пара связей. Но если наславать и усложнять всю эту хуйню, появляется хуева куча таблиц и куча связей, целая сеть ебучая, как сеть петри и нейросеть, в которой уже хуй разберёшься, без аккуратног сдвигания окошек, которые уже не лезут в окно схемы данных, и без отслеживания связей между этими вот - таблицами ебучими. Нахуй нужно столько таблиц, и связей между ними? МОЖНО КАК-ТО ПОПРОЩЕ? Вот основной вопрос, который задаёшь себе, при проектировании сложной модели данных. Следующий вопрос... А что насчет оптимизации? И/или нормализации? В нормализацию я не могу, ибо я не изучал все эти отношения и реляционную алгебру между ними, у меня тупо таблички и связи, здесь. И вот число табличек и число связей, надо бы как-то уменьшить. И внезапно, анон, говорит, что можно описать любую реляционную модель тремя таблицами (или четырьмя, или даже одной, той, god_table), но ибаццо с такими данными через хуеву кучу триггеров, мягко сказать, не нормально. Значит база нихуя не нормализована, данные не имеют нормальную форму. Но я же, узрел, в трех таблицах (ну или четырех, блядь, которые так и не гуглятся), результат нормализации ЛЮБОЙ СХЕМЫ ДАННЫХ, и как-бы даже УНИВЕРСАЛЬНУЮ МОДЕЛЬ ДАННЫХ, в которой можно уместить ЛЮБУЮ МОДЕЛЬ. Отсюда и понос этот весь.
>>1907360 >На деле важнее перфоманс, поэтому в реальных проектах часто прибегают к денормализации схемы БД. Я так понимаю. денормализация ведёт к дублированию данных, или просто растёт сложность модели данных, в смысле число таблиц и свзей между ними? Потому что, как я понял, из примера анона >>1905932 с его универальной одной, общей, god_table, одна таблица, получается, это хорошо и прекрасно, но внутри неё данные - дублируются пиздец как. И если снизить дублирование данных, придётся делать таблицы-списки с уникальными элементами, и на них уже ссылаться из других таблиц, а значит растёт число таблиц и число связей между ними, и усложняется схема данных - то есть растёт сложность самой этой вот - реляционной модели данных. Хотя да, растёт перформанс, ведь при записи/обновлении, достаточно обновить одно значение, а не делать кучу INSERT и UPDATE, ну а чтение достаточно закешировать, да и всё на этом.
>>1907662 >>1907635 Без негатива, но я даже не вижу, что тут нам можно обсудить. Ты тратишь время на какую-то эзотерику уровня Brainfuck. Просто рекомендую этого не делать.
>>1907635 > Но если наславать и усложнять всю эту хуйню, появляется хуева куча таблиц и куча связей, целая сеть ебучая, как сеть петри и нейросеть, в которой уже хуй разберёшься Хотя, тут остановлюсь.
> если наславать и усложнять всю эту хуйню А если не наслаивать и не усложнять, то получается уже по-другому. Думал об этом?
Везде, где я работал, были микросервисы (я молодой и времена монолитов не застал), и у каждого микросервиса была своя БД. Обычно в БД микросервиса не больше десяти таблиц. Это позволяет немного декомпозировать сложную схему большой БД и разделить ответственность (как между отдельными частями проекта, так и между командами разработчиков).
Плюс ко всему, часто по схеме БД можно увидеть доменные модели сервиса. Я стараюсь первым делом строить схему БД, когда выкатили функциональные требования и начали выкатывать макеты интерфейса (если есть) для новой фичи. Если ТЗ не очень хорошее, то уже на этом этапе возникает куча вопросов.
Модель данных -- это очень важная часть решения задачи, она твой помощник и она фундамент твоей работы. Ты пытаешься от неё отказаться и называешь это какой-то оптимизацией, но фактически это эзотерический эксперимент, и оптимизирует он что-то в том же смысле, в каком коронавирус оптимизирует население страны.
>>1908077 >Без негатива, но я даже не вижу, что тут нам можно обсудить. >Ты тратишь время на какую-то эзотерику уровня Brainfuck. >Просто рекомендую этого не делать.
Быть может, если я проясню детальнее, то станут более понятными мои устремления, и собственно, исследовательский интерес.
Значит так... В теорию баз данных, я только вкатываюсь. По какой причине? Да банально, по причине того, БД поддерживают индексацию, ибо загружать огромные JSON-файлы, коими можно представить таблицы (а логику же обработки данных таблиц - увязать в приложении), загружать JSON, скажем в 5 гигабайт, да ещё и в RAM, мягко-сказать, нецелесообразно.
Итак... Вкатываюсь в базы данных, и вижу, что она состоит из таблиц, которые не грузятся в память, которые проиндексированы, которые хранятся либо в файле, либо на сервере, а доступ к данным осуществляется по заранее организованным - SQL-запросам. Уже заебись.
А как же строить эти базы данных? Вижу, что есть целое направление - проектирование баз данных, изучающее МОДЕЛИ ДАННЫХ. Также, я вижу, что преимущественно, в СУБД, модель баз данных - реляционная, и что к ней можно свести любую, как иерархическую, так и... Внезапно - СЕТЕВУЮ МОДЕЛЬ! От словосочетания "сетевая модель", у меня в памяти всплыают нейросети, и всё то, что они могут, в том числе и распознавание каптчи, и нейросетевой параллелизм, мозг, и всякое такое. А ведь действительно, проще организовать данные в виде сетевой модели, нежели строить иерархию, с дублированием данных. Ну так вот, всё это - сводится к реляционной модели. А как? Опять же, куча таблиц, и куча связей. Далее, я попытался потыкать это, чтобы ощутить на практике. В итоге наварганил эту схему данных: >>1901240 глядя на которую, я вижу некую СЕТЬ ИЗ СВЯЗЕЙ. Это почти как сетевая модель, но только не оптимизированная. Внезапно, анон ITT, говорит, что любую реляционную модель можно свести к нескольким таблицам, что показалось мне весьма охуенным, ведь если любую реляционную модель, можно представить в некоей универсальной форме, то почему бы не писать в ней сразу, ВСЮ СЕТЬ, проектируя базу данных, и дополняя её, по мере выращивания и наращивания сети? Как это сделать, толком не сказали, но один анон предложил огромную одну таблицу - god_table, которой дофига данных дублируется, естественно... Ну это, мягко говоря, не очень сетевая модель, и скорее иерархическая, потому что именно в иерархической модели дублирования дофига, по сравнению с сетевой моделью. Я же, со своей стороны, вот здесь: >>1907662 попытался построить именно сетевую модель, с минимальной избыточностью, но в итоге, выходит, что получается слишком дофига таблиц-списков, из которых, сеть приходится строить, как строят микросхемы из логических элементов (твоя аналогия с "изотерикой уровня Brainfuck"). Посему, хотелось бы найти некую "золотую середину", если она есть, конечно. Нечто такое универсальное, чем можно ОПТИМАЛЬНО описать - АБСОЛЮТНО ЛЮБУЮ МОДЕЛЬ ДАННЫХ, например, модель - абсолютно любой информационной системы.
Сходу, возникает вопрос: а существует ли модель данных, которая не может быть представлена в виде реляционной модели? Ведь насколько я понимаю, реляционная модель выбрана как основная, именно из-за универсальности своей... Достаточно ли универсальна она, на самом-то деле?
>А если не наслаивать и не усложнять, то получается уже по-другому. Думал об этом? Ну, вот есть модель данных, из пикчи >>1901240 а надо добавить ещё две таблички: Deposits (|id(integer)|UserWalletID(integer)|amount(text)|txid(text)|) Withdrawals (|id(integer)|UserWalletID(integer)|amount(text)|txid(text)|) и две связи с табличкой UsersWallets... И вот так, число таблиц и связей, может расти, они наслаиваются пиздец как, сеть растёт же, база растёт... Может быть ещё одна модель данных в базу данных встроена, в том числе и сложная - ещё одна растущая сеть... Ты говоришь, лучше сделать много БД, с моделями попроще... Однако, куча баз данных, это ещё хуже чем куча таблиц в одной БД, особенно если это серверная СУБД. Это чё, бля, на каждую базу по серверу впиливать?
>Модель данных -- это очень важная часть решения задачи, >она твой помощник и она фундамент твоей работы. >Ты пытаешься от неё отказаться и называешь это какой-то оптимизацией, >но фактически это эзотерический эксперимент, >и оптимизирует он что-то в том же смысле, в каком коронавирус оптимизирует население страны. нет, нет, тут не совсем так ты меня понял. Я пытался выбрать именно оптимальную структуру БД, и понять как строить - на базе неё любые модели данных. Хотя, впрочем, я описал уже выше, в этом посте, как, к этому, я подошёл.
> тут не совсем так ты меня понял К сожалению, я тебя понял лучше, чем ты понял меня.
> насколько я понимаю, реляционная модель выбрана как основная, именно из-за универсальности своей... Реляционная модель была выбрана из-за того, что суровые матанщики создали мощный теоретический фундамент, на котором можно было строить СУБД, которые бы не проёбывали данные и давали кучу гарантий при правильном использовании. Это не SIlver Bullet, но достаточно мощная штука, решающая реальные задачи лет уже пятьдесят.
> а существует ли модель данных, которая не может быть представлена в виде реляционной модели? Графовая модель, например. На реляционки она натягивается примерно как сова на глобус, сейчас для этого обычно используют что-то вроде ArangoDB. Там есть ACID и нет SQL, кстати.
> Однако, куча баз данных, это ещё хуже чем куча таблиц в одной БД, особенно если это серверная СУБД. > Это чё, бля, на каждую базу по серверу впиливать? Давай, короче, объясню, что файл -- это тоже база данных, ведь он хранит данные. А файл -- это, в свою очередь, именуемая область памяти, как в универах учат. Только хранить серьёзные данные в файле и обеспечивать их целостность на протяжении большого количества времени выходит очень неудобно и сложно. СУБД занимается хранением, изменением и извлечением данных из БД. В СУБД может быть практически неограниченное количество БД, как плейлистов в музыкальном проигрывателе. Ни о каком сервере на каждую базу данных речи не идёт.
> Ну, вот есть модель данных, из пикчи >>1901240 > а надо добавить ещё две таблички: > Deposits (|id(integer)|UserWalletID(integer)|amount(text)|txid(text)|) > Withdrawals (|id(integer)|UserWalletID(integer)|amount(text)|txid(text)|) > и две связи с табличкой UsersWallets... В реальном мире был бы микросервис для авторизации, аутентификации и всей пользовательской залупы. Остальные микросервисы бы ничего не знали о пользователе, кроме его идентификатора.
Также были бы отдельные микросервисы для:
1. Ассетов пользователей; 2. Ввода-вывода бабок; 3. Личных сообщений и оповещений; 4. Всей биржевой хуйни (плюс ещё микросервис для обновлений графиков, котировок и стаканов в реальном времени по вебсокетам; плюс сам биржевой сервис можно разбить на несколько наверняка, но я об этой предметной области ничего не знаю из того, что не показывают в кино).
Плюс ещё микросервис-шлюз для API.
В каждом микросервисе было бы по 4-5 таблиц примерно, и каждый из них бы отвечал за очень изолированный и понятный человеку участок работы. Плюс какой-нибудь сервис личных сообщений ты бы написал один раз и годами в него не заглядывал, он бы просто работал.
Не то что бы это лучший подход, но он хорошо работает в реальном мире. Кроме того, в Постгресе есть возможность использовать различные схемы для БД, и там вполне себе можно твою усложняющуюся большую схему раздробить на несколько более мелких и простых для понимания: https://www.postgresql.org/docs/9.1/ddl-schemas.html
> JSON, скажем в 5 гигабайт, да ещё и в RAM, мягко-сказать, нецелесообразно Монгу потыкай. Или нет.
> Внезапно, анон ITT, говорит, что любую реляционную модель можно свести к нескольким таблицам, Это хак, чтобы впихнуть в реляционку что угодно, отказавшись как раз от реляционной модели, гарантий, нормальных запросов и понятной схемы. Ты как бы берёшь реляционку, но используешь её как Excel. Это эзотерика и брейнфак. Реляционки такое делать позволяют, реляционная теория -- нет.
> что показалось мне весьма охуенным, ведь если любую реляционную модель, можно представить в некоей универсальной форме, Ну, думаю, я тебе немного проиллюстрировал, что ты не особо понимаешь, какие именно проблемы реляционные СУБД решают и думаешь вообще не в том направлении, рискуя проебать кучу времени на хуйню и стать чуваком с пика, чего я тебе не желаю.
Сап! Супер-быстрый low-iq вопрос по SQL: База данных - в формате, как выделено зелёным на скрине. Как написать запрос, чтобы результат был как выделено синим на скрине?
>>1910449 Хех, я предполагал что-то такое, но без понятия, как это сделать. Мог бы кто-нибудь написать запрос для примера со скрина? А далее я смогу перенести на свою задачку.
select column1, max(case when column2 = 1 then column3 end) max(case when column2 = 2 then column3 end) max(case when column2 = 3 then column3 end) from product group by column1
>>1909694 >Графовая модель, например. На реляционки она натягивается примерно как сова на глобус, сейчас для этого обычно используют что-то вроде ArangoDB. Там есть ACID и нет SQL, кстати.
https://ru.wikipedia.org/wiki/Графовая_база_данных#Описание >Для задач с естественной графовой структурой данных графовые СУБД могут существенно превосходить реляционные по производительности, а также иметь преимущества в наглядности представления и простоте внесения изменений в схему базы данных.
Но там не сказано, что графовая модель несовместима с реляционной. Это так, или всё-же можно преобразовать любую графовую модель в реляционную, и реляционная модель достаточно универсальна, чтобы представить ею - абсолютно любую модель, в том числе и графовую? Пусть сложно, пусть не очень наглядно, но всё же...
>>1911537 Что-то вроде одной таблицы связей вершин графа, с указанием там направления этих связей и силы этих связей может поместиться в реляционную модель, я думаю. Но если так мозги описывать, например, с их 100 миллардами нейронов, и по 10000 связей по каждому ихнему дендриту их, каждый-с-каждым, то пиздец получается какой-то, пиздатая таблица многие-ко-многим, c 1000 триллионов строчек, и ещё и весовые коэффициенты надо указать, в отдельном поле у неё. Охуенный граф.
>>1911537 > или всё-же можно преобразовать любую графовую модель в реляционную Можно вообще любое говно преобразовать в типа-реляционное, это выше обсуждалось. Это будет работать, но это будет неправильно, потому что ты потеряешь свои концептуальные и логические модели данных, оставив только физическую и используя СУБД как серверный Excel для хакеров.
> не сказано, что графовая модель несовместима с реляционной Понятие совместимости очень растяжимое. До 1999 года в стандарте не было рекурсивных запросов и CTE, поэтому чистый SQL не позволял делать некоторые графовые запросы. Нужно было на PL/SQL расписывать свою процедуру для рекурсивных запросов, то есть пиздец. Сейчас со всеми костылями можно графы в БД обходить, но это всё ещё медленно и мало где приемлемо. Реляционки могут хранить какое угодно говно, могут обрабатывать какие угодно запросы, но будут эффективны только в реляционных задачах. Чуда нет.
Погугли, что ли, курсачи какие-нибудь по проектированию БД. Там должны быть расписаны шаблонно все этапы. Если ты не совсем ещё потерян, то поймёшь, что у тебя не должна God Table получиться после концептуального и логического этапов проектирования.
>>1869616 (OP) Согласно принципам архитектуры Фон-Неймана, в частности, согласно "принципу однородности памяти", команды (инструкции) и ДАННЫЕ, хранятся в одной и той же памяти.
>Команды и ДАННЫЕ хранятся в одной и той же памяти и внешне в памяти неразличимы. >Распознать их можно только по способу использования; >то есть одно и то же значение в ячейке памяти может использоваться и КАК ДАННЫЕ, >и КАК КОМАНДА, и КАК АДРЕС в зависимости лишь ОТ СПОСОБА ОБРАЩЕНИЯ К НЕМУ. >Это позволяет производить над командами те же операции, что и над числами, >и, соответственно, открывает ряд возможностей. >Так, циклически изменяя адресную часть команды, >можно обеспечить обращение к последовательным элементам массива ДАННЫХ.
Я знаю, что SQL не является Тьюринг-полным языком программирования, и вообще, вроде как, это даже и не язык программирования, хотя, также как HTML, CSS и XML, он - обладает всеми свойствами, позволяющими классифицировать его, как декларативный язык программирования.
Вопрос. А возможно ли, внутри базы данных, хранить в виде данных - адреса и команды для обработки этих вот данных, и сделать из базы данных, полноценное приложение, могущее в тьюринг-полноту, а значит и в реализацию абсолютно любых программ, которые можно исполнить на компе? То есть, блядь, ну, то, что адреса и команды, можно в таблички записать, это понятно, но можно ли сделать это самодостаточным, или же надо какую-то ёбу и расширение дополнительное, чтобы оно ИНТЕРПРЕТИРОВАЛО по-разному эти вот ДАННЫЕ, либо как ДАННЫЕ, либо как КОМАНДЫ, либо как АДРЕСА, и чтобы ОНО, это расширение, как-бы ДОПОЛНЯЛО, всю хуйню, которая не является тьюринг-полной, а является какой-то НЕПОЛНОЙ, блядь?
>>1913624 Перечитал этот пост, и чё-то от прочитанного на ум приходит следующее... Вот короче есть процессор, с его тьюринг-полнотой, и есть RAM, хранящая ДАННЫЕ. Есть, короче режим загрузки, когда в процессе загрузки ГУДИТ тьюринг-полный проц, а есть, значит - режим гибернации или режим сна, которые просто записывают состояние RAM на жесткий, а при выходе из "ждущего" и "спящего" режима - c жесткого диска, память просто втекает в RAM, и этот вот тьюринг-полный процессор, он - не гудит дохуя.
Короче, сразу на ум спадает, просто записывать в базу данных, BLOB'ами, результаты вычислений, и если надо процу произвести вычисление с инструкции 1 по инструкцию 2, то, можно было бы - просто считать из значения BLOB, в базе данных, уже готовый результат вычислений, как ДАННЫЕ, вместо того, чтобы вычислять всю эту хуйню.
Это походит на что-то вроде кэширования... Но нет, это не совсем то. Вопрос скорее в том, возможно ли наславивать неограниченное количество закэшированных данных, в базе данных, так, чтобы производить минимум вычислений тьюринг-полным устройством? Если возможно, то возможно ли, после всего этого, произвести оптимизацию и нормализацию данных так, чтобы ужать базу данных с этими вот закэшированными BLOB'ами, в минимальные размеры, и чтобы она была оптимальной эта база данных, а не раздута до ебических размеров? Что-то вроде универсальной логической схемы для конкретного приложения, имеющей минимальный размер. Что-то вроде скомпилированной программы, но внутри базы данных.
>>1913624 Если язык не является тьюринг-полным, то нельзя, какие абстракции в рамках языка ни строй, абстракции всегда ещё более ограниченные, чем сам язык наверняка это как-то связано с теоремой Гёделя о неполноте, но мне как-то пох. Впрочем, пишут, что SQL тьюринг-полный, если юзать рекурсивные запросы. > расширение Расширениями можно хоть пустое множество Ø сделать тьюринг-полным. Так можно прийти к хранению исходного кода хоть на питоне в БД и запуске его в питоньем интерпретаторе с помощью этого расширения.
>>1913638 Ясен хуй, что если результаты вычисления могут быть разбиты на части атомарные, которые уже есть в базе данных, то проще эти результаты вычисления не писать BLOB-ами ебическими, а вписать внутрь реляционной БД - в виде таблиц, и записей в таблицы, по которым легко и просто найти результат, вместо того, чтобы его вычислять. И как-бы по частоте использования, уже, обращаться к этим записям, и отсортировать их внутри таблиц, и взаимосвязать заебато.
>Расширениями можно хоть пустое множество Ø сделать тьюринг-полным. >Так можно прийти к хранению исходного кода хоть на питоне в БД и запуске его в питоньем интерпретаторе с помощью этого расширения.
Так вопрос был в том, будет ли вся эта ёба, более оптимальной по размеру, из-за её реляционости универсальной, которая может быть оптимизирована и нормализирована. Или же не будет? Всё-таки, скомпилированные программы, имеют малый размер, и являют собой ничто иное как ДАННЫЕ на жестком диске/флешке/SSD, а вот уже СПОСОБ ИСПОЛЬЗОВАНИЯ этих данных, при запуске программ этих вот, скомпилированных, делает из них ПРОГРАММЫ, а не просто ДАННЫЕ (которые, как я подозреваю, могут быть и в базе ДАННЫХ, и не просто EXE-шники, BLOB'ами, блядь, а в реляционных базах данных, то есть, в виде реляционных данных, какой-либо реляционной модели программы, и тупо - в виде таблиц и связей между ними). Ясное дело, что в виде таблицы можно любой HEX-код расписать, как в HEX-редакторах он и выводится, таблицей. Но такой способ хранения - не очень оптимальный, как по мне. В общем, взглянул так, на всё это, и думаю, быть может удсться найти что-то прорывное, и невъебенное здесь.
>>1913645 > будет ли вся эта ёба, более оптимальной по размеру, из-за её реляционости универсальной, которая может быть оптимизирована и нормализирована. Не будет. Нормализация - это не способ абсолютного сжатия данных до возможного минимума. Даже архиватор порой справится лучше. > СПОСОБ ИСПОЛЬЗОВАНИЯ этих данных, при запуске программ этих вот, скомпилированных, делает из них ПРОГРАММЫ, а не просто ДАННЫЕ Да, и ничего сверх этого здесь не выдумать. SQL-запросы - это просто один из способов использования данных, и даже если суметь заставить СУБД читать "команды" из таблицы и выполнять их, это концептуально ничем не отличается от того же процессора, выполняющего команды над данными в ОЗУ.
>>1913655 >Нормализация - это не способ абсолютного сжатия данных до возможного минимума. >Даже архиватор порой справится лучше. Кстати, я уже думал над этим, то есть над сжатием данных, с помощью "реляционной модели данных", и думал, в контексте "принципов построения Кодов Хаффмана": https://ru.wikipedia.org/wiki/Код_Хаффмана "Код Хаффмана", позволяет сжимать данные, оптимально кодируя их, а именно - представляя символы различными, короткими кодами, в зависимости от частотности использования их, причём так, чтобы символы встречающиеся наиболее часто, кодировались более короткими кодами, которые в итоге - встречаются чаще более длинных кодов.
Кодирование Хаффмана, сводится к построению двух (трех) таблиц из уникальных элементов: 1. Таблица символов, отсортированных по частоте их встречаемости. 2. Таблица кодов Хаффмана. 3. Таблица для связи символа из первой таблицы и кода (связь 1 к 1, поэтому опционально). Для морзянки, например, несколько символов могут иметь один и тот же код, поэтому эта, третья таблица, тут кстати, ведь связь между уникальными кодами и уникальными символами, уже - многие-ко-многим.
Ну так вот, о чём я речь вёл? Ах да... Сжатие данных, с использованием реляционной модели. Выше, вот здесь: >>1907249 я пришёл к тому, что любую реляционную модель, можно представить таблицами-списками, содержащими только уникальные элементы (и пары их).
Если так, то очевидно то, что наиболее часто-встречающиеся, и наиболее часто-использующиеся данные, в базе данных, в том числе и большой, должны бы, в результате оптимизации, иметь ID не надцать трильйонов, а 1, чтобы меньше данных хранить, а остальное говно, неуникальное, должно бы быть вычищено нахуй из базы данных, и если оно имеет место быть в каком-либо месте, то оно может быть просто - представлено ссылкой на уже имеющуюся запись.
И вот так, оставляя лишь уникальные элементы, и связи между ними - можно было бы сжать даже пиздейшую "базу данных". потому что связи, это просто связи, там не так много инфы надо, чтобы сохранить только их (два элемента, направление связи между ними, и опционально ещё - сила связи). Всё это может поместиться в одну табличку, и ебись оно конём. Это намного пижже, вместо того, чтобы расписывать дохуя дублирующихся данных, дуя теми же BLOB'ами, базу данных до пиздейших размеров.
Это я, так, примитивно смотрю. Возможно существуют ещё более крутые алгоритмы оптимизации баз данных, и их минимизации, и возможно даже, какой-то базоданный алгоритм, невъебенный, можно было бы использовать, ВНЕЗАПНО, для эффективного сжатия НЕСЖИМАЕМЫХ ДАННЫХ. Мне откуда знать? Это скорее математики и профессора, наверное, шарят лучше, в этом направлении... А я, как-бы, издаля поглядываю на всё это, со своим неполным пониманием, и всё-таки, чё-то, да вижу уже.
>>1913815 Эхо старой войны между программистами и дба. В принципе все промышленное IT - это борьба с долбоебизом и случайными ошибкам. В программе Laba1.pas или научном исследовании, где из долбоебов один ты - можешь не создавать.
Сап, котятки. Поясните, насколько плохо пользоваться такими штуками как констрейнты и не дублировать их в коде?
То есть по сути бизнес логика в базе данных. Учитывая что навешивание бизнес логики происходит в миграциях и под контролем версий.
Ну или там занесение сохранёнок через миграции? Где-то у вас в продуктах так делают, или на петухоне всё пишут связанное с бизнесой, а максимальный констрейнт это unique?
>>1916951 Да, максимум проверок в БД - это NOT NULL/UNIQUE/REFERENCES. Хз насчёт общепринятых причин считать логику в БД чем-то плохим, но как минимум такое неудобно дебажить + проверки в коде всегда можно по-быстрому переписать без новых скриптов миграции.
Сосоны, если я решил 50 задач полностью сам включая 3 и 4 уровень на скл-ех в разделе обучения, можно начинать поиски позиции джуна аналитика с предположением, что я достаточно знаю мат стат и теорвер?
>>1917213 Как через дебаггер подключиться к базе? Никак. Тестики укажут, что есть ошибка, но не объяснят, в каком месте она возникает. Если у тебя большая и сложная бизнес-логики, где что-то сеттится в разных местах и в зависимости от условий, что-то копируется, что-то не копируется, без дебаггера охуеешь её искать.
Сроки горят чаще всего на дебаге. Тебе дают заказывают фичу. Ты её имплементишь. Во время заэстимейченное на эту задачу входит написание тестов. Оно прогнозируемо.
А время дебагинга бывает очень разное, его невозможно спрогнозировать и чаще всего заэстимейтить тоже.
>>1917300 Ну, у нас тесты пишут только для определённых случаев, в целом код ими мало покрыт, но на написание времени уходит много. Да и даже когда они падают, причину всё равно приходится искать дебагом, ибо что-то прийти может из непокрытого кода из метода на 200 строчек (лол). Мартина в закладки добавляю.
>>1916951 Смотри, расклад такой. Сохранёнки не юзай. Сохраненки говно.
Проблема в чём, проблема в том что львиная доля data intensive приложений о том как должны выглядить данные. И тебе придется огромную часть кода сувать в СУБД.
А PL язык хуже, чем какой-нибудь питухон, руби, пхп, жава.
В нём просто не будет тех фич, не будет однострочной хуйни, не будет библиотечек и тд.
Примитивный язык.
> констрейнты
Смотри, если это закон логики, там типа в таблице хранится промежуток времени в виде 2х дат. То тут констрейнты это хорошо.
А если там бизнес логика которая может меняться, то нет. Пример - у нас есть сайт соцсеть. Минимальный возраст для регистрации - 13 лет. Но тут Путин выпустил закон что, нельзя до 15 лет.
То есть у тебя в базе уже есть невалидные данные, прикинь как охуенно.
Это должно отсекаться в валидаторе, ясен хуй.
>>1917322 А дело в том что ТДД - это другое. Там ты пока пишешь тест лучше, поймешь хуле тебе надо сделать. В итоге ты просто дольше печатаешь. Но ты ещё пойми что в ебучих скриптоязыках всё это говно удобно сделано ибо там иначе сложно, а какой-нибудь JUnit неудобный пиздец.
Ещё, проекты очень большие это хоть и правда жизни, но это плохо. Надо разбивать на маленькие.
Аноны когда нужно заниматься поддержкой индексов? Вот допустим есть таблица с внекластерным индексом, новые значение поступают регулярно, если удаляются данные, то всегда только самые старые, обновлений нет. Нужно ли при таком раскладе обслуживать индексы? Насколько я понимаю переиндексацию надо делать если данные обновляются/удаляются за промежуточный период, если с краёв накидывют, то и так работает. или я не прав?
Кто-нибудь может помочь с простой для меня неподъемной задачей аля создать мини-базу данных в SQL? Я неебу как это работает, у меня не работает ничего, я проебала всю теорию и все практики, а нужно сделать экзамен
Делать email PK не очень хорошо по следующим причинам. 1) Сравнение с ID это очень частое сравнение, сравнивать строки дольше чем циферки 2) Связывать таблицу с другими по эмайлу это лишняя морока, хранишь больше данных и дольше джойны 3) Заёбы с апдейтом. Допустим ты захочешь поменять ID. Тебе придётся делать сложные апдейты(связанные таблицы). Вообще изменять ID не советуют. Даже если твой софт не позволяет менять email, фамилию-то можно поменять? Тянучки замуж выходят так-то.
>>1920240 еще вопрос. я щас колупаюсь с внешними ключами как лучше назвать колонку из табл сообщений с внешним ключом,если он ссылается на id пользователей? также ?
Анон, привет, юродивый челом бьет, подскажи, как переписать данное условие на AND и OR, и что вообще за форма записи такая: SELECT * FROM demo where (name, id) >= ('limit', 5)
Пацаны выручайте, мне нужно БЫСТРО вкатиться в SQL и вообще базы данных, ничего по этому не знаю вообще, кроме синтаксиса, тестовое горит, посоветуйте курсы, видосы с ютаба, книжки, что угодно вообще, онегай!
Нужно небольшая, маленькая, околореялционка (типо дополнительные поля v), само kv и дерьмо уровня graph/doc/bson. Чтобы всё это было acid. А еще чтобы оно распределённое было. И маленькое, а не 5мб постгреса. А еще чтобы можно был на клиентском устройстве базу держать, синхронизировать с серверами и в локальной сети строить acid, лол, но это манямечты Ну и офк без интерпрайс версий, когда функционал обычной версии специально обрезают.
>>1923715 >>1923736 Проиграл с шизофреника. Ты в курсе сколько говна нужно поверх sqlite писать, чтобы это было пригодно на проде? Или ты кроме домашних скриптов нихуя не писал?
>>1923779 Тут тебя тоже придется к шизиками отнести, если ты думаешь что sqlite правда можно в прод ставить. Оно максимум для встройки, да и то уже давно есть варианты получше.
А то что я описал - уже есть. Couchbase lite (вместе с сервером) тот же. Или YugaByteDB. Первый коммерческий, второй хз что там. UnQLite впринципе заебись, хуй знает, кокое-то оно страшное. Нужно больше вариантов, но я уже заебался уже схемы составлять, то на таблицах, то на ключах, и думать куда документы в тысячи строк делать. Уублят.
>>1921813 Спасибо, анон! Нагуглил еще вариант названия tuple comparision и условие правильнее будет таким: name > 'limit or (name = 'limit' and id >= 5)
Ораклисты, подскажите, каким образом можно написать запрос, чтобы положить БД? На практике такое выстрелило один раз, когда в цикле c апдейтами с промежуточными коммитами писал запрос тяжелый с 10+ left join. В итоге запрос после n итераций просто завис. Опытный админ назвал нубом и сказал, что данные читались из сегмента отката. Но как, если после каждой итерации происходит коммит?
>>1923819 >>1923324 > околореялционка > типо дополнительные поля v > само kv > дерьмо уровня graph/doc/bson > Чтобы всё это было acid > чтобы оно распределённое было > И маленькое > прод > шизик > прод > типо дополнительные поля v > шизик > то на таблицах > то на ключах > документы в тысячи строк делать > шизик > арод
Поясните за SQL сервер, креденшиалы блять, они мне нахуй не нужны эти креденшиалы ваши. Почему я не могу просто так делать манипуляции с базой данных, мне похуй на всякие привилегии и прочую поебень, зачем мне какие-то логины и пароли? А если я хочу свой пет проект с локальной базой данной перенести на другой комп, мне тоже придется авторизоваться на сервере? Как сделать переносимость? Я так понимаю всякие игрули че-то пишут в дб и читают оттуда, и никакой хуйни типа введите пароль от винды? Как это вообще работает?
Ещё хотел поинтересоваться, 1 транзакция insert на 10 строк лучше и быстрее, чем 10 раз по 1 строке? Если допустим, мне нужно читать данные, скажем, из большого файла и конвеерно записывать их в базу, как эффективней это сделать?
>>1924399 ну потому что обычно с БД работало десктопное приложение и у каждого был свой пароль.
сейчас всем похуй, но бывает что у каждого микросервиса свой пароль.
Вообще, главная концепция Сесурити в том что, ты заранее не знаешь где именно ебанет и вынужден усложнением и избыточными перекрывающими друг друга мерами. Разве это не очевидно? как такие вопросы возникают вообще?
>>1924399 >Ещё хотел поинтересоваться, 1 транзакция insert на 10 строк лучше и быстрее, чем 10 раз по 1 строке? Да. >Если допустим, мне нужно читать данные, скажем, из большого файла и конвеерно записывать их в базу, как эффективней это сделать? Ну так почитай документацию. Впрочем, есть и универсальный метод: INSERT INTO .. VALUES (..),(..),.... ; (вроде в оракле такой синтаксис не прокатит)
Ананасы, ткните где можно почитать про синхронизацию баз. У меня есть одно центральное remote хранилище, и несколько приложений со своими локальными базами. Как сделать чтобы в цетральной бд всегда были последние данные? Например в клиенте изменились данные, он их отправил в бд. А пото просыпается другой клиент со старыми данными, видит что в бд лежит другое и тоже обновляет, в итоге мы имеем проебтданных. Неужели к каждой записи надо добавить поле последнеего изменения и сверять каждый раз?
>>1924506 MariaDB Galera cluster например. Но это тебя не спасет если клиенты уходят в оффлайн, а потом снова появляются онлайн, но уже с записями, которые будут конфликтовать с записями в кластере.
>>1924044 Но ты же серьезно шизофреник. Бомбанул и гринтекст с кариночкой высрал. SQlite на проде, ору нах с шизика
>>1924506 >>1924560 Для этого есть всяческие субд и алгоритмы вроде Raft. Гуглить и изучать через поисковой запрос "кластеры, орекстраторы", проблема называется "state machine replication". Ничего там не конфликтует, если багов нет.
>>1924506 а схуяли у тебя клиент "просыпается"? есть еще классическая круговая репликация в mysql, не galera. Это дубовая методика, но работает. Аккуратно только таблички с engine=blackhole создаешь на каждом.
>>1924560 >>1924925 >>1924869 > Но это тебя не спасет если клиенты уходят в оффлайн, а потом снова появляются онлайн, но уже с записями, которые будут конфликтовать с записями в кластере. Вот как раз это - моя проблема. У меня клиенты это приложения на ведре, пеке и тд. Они 146% онлайн изредка, когда юзер запускает это самое приложение. А данные должны быть везде одинаково.
Мне не подходит репликация, просто потому что основная база это постгрес, а клиентские - что туда запихнут создатели. Например в qt и ведре это SQLite, в других фреймворках может быть по другому.
>>1924984 Ну вот у меня пока идея только одна - добавить поле с датой послекднего обновления и каждый раз проверять. Но я почему-то уверен, что есть способы лучше, и люди сталкивались с такой проблемой до меня. И может быть даже выработали конкретный алгоритм решения.
>>1924869 Дядя, ты сам то хоть раз кластер настраивал или только в ютубе видел. Почитал я про твой raft хуйня без задач, где право на запись имеет только мастер выбранный консенсусом узлов кластера. Проблема с которой столкнулся анон называется выход из split-brain
>>1924986 Сделай денормализацию базы. Пусть клиенты выгружают данные в одну таблицу, загружают из другой, каждый клиент пусть еще генерит себе уникальный айдишник. На центральном постресе напиши хранимую процедуру которая будет перекладывать данные по кд из сырой таблицы в готовую для отдачи.
>>1925212 Возможно я не понял что ты имеешь ввиду, но как это решит проблему того что неизвестно какие данные актуальные? Клиенты ведь всегда пишут в одну сырую таблицу. Сам посуди, один клиент отправил новые данные в сырую таблицу, постегрес их скопировал в основную, а потом проснулся другой клиент, увидел что его данные не совпадают и решил отправить свои. Разве что прикрутить локальную проверку на то, были ли уже данные отправлены или нет, и если были а данные не совпадают, значит их надо скачать.
>>1925216 В упор не вижу необходимости клиенту что то решать. Свои выгрузил, новые скачал. Точка. А какие данные актуальные пусть решает сервер. Можно к серверу push нотификацию прикрутить, чтобы он сообщал клиентам что данные обновлены.
А у тебя как то наоборот. Клиенты выкачивают базу, потом что то мержат со своими локальными данными. Потом закачивают. А потом оказывается что пока он выкачивал и мержил, там уже другой клиент что то закачал. Ой.
>>1924982 Раз у тебя постгресс - смотри субд по постгрессу. Вот тут https://github.com/zalando/patroni смотри, найдаешь всё что нужно. Используй dcs, используй самые примитивные алгоритмы, прочитай хотя бы про них.
>>1925209 > raft хуйня без задач, где право на запись имеет только мастер выбранный консенсусом узлов кластера > называется выход из split-brain Сам-то чуешь что пишешь? Или ты тот шизик который sqlite собрался на сервер пихать? Рафт это выбор лидера. Если лидер одни - всегда, гарантированно, будет одна мастер бд. Если будет одна бд - никакой несогласованности не будет. Какой еще сплитбрайн?
>>1925360 Я вообще мимо проходил и лишь заметил что ты далек от практики. У тебя гео распределенный кластер развалился на две части. Каждая выбрала себе мастера. Половина клиентов повисла на одном половина на другом. Потом магистральный провайдер починил оптику. И все сосалово. Хуй у тебя база сольется если там были апдейты или удаления и хуй твой раст тебе в этом поможет
>>1925379 > У тебя гео распределенный кластер развалился на две части > магистральный провайдер починил оптику Шиза та еще конечно, ололо. Наверное ты не в курсе, но в каждом дц есть несколько провайдеров и несколько линий. А в океяне несколько сотен кабелей проложено. Погугли как интернет работает. > Половина клиентов повисла на одном половина на другом Это уже маняфантазия про децентрализованные сети в условиях военного времени, когда межконтинентальные кабели перерезаны. О таком маняфантазируют в другом разделе. И конечно же тут работают другие механизмы, а не raft. Он прост для продакшена сделан, а не для этих маняфантазий. > Хуй у тебя база сольется Базы сливаются по журналу обычно. В условиях военного времени, если никаких журналов нет, кабели перерезаны и нужно слить базу - придется ручками сливать. Вряд ли клиенты обидятся что им целый час старые данные отдавали, война как-никак. > ты далек от практики Ну ты понел.
>>1927138 Она в LXC-контейнере в проксмоксе. И сам гипервизор говорит, что не ест и htop внутри тоже... Чую нужно как-то conf настроить, но там какие-то суринамские понятия, за несколько подходов не смог осилить.
Здравствуй, дорогой анон, поможешь пожалуйста с лабой по бд? Как реализовать ветвление на er-диаграмме? Человек, принёсший в ломбард предмет, может иметь разные цели, если например, под залог, то предмет сразу отправляется на склад, а если он уже продан, то отправляется на витрину. Мне создать отдельную сущность для продажи/залога?
>>1928296 В таблицах "Склад" и "Витрина" по столбцу thing_id с ссылкой на таблицу предметов, а "ветвление" определяется наличием или отсутствием соответствующих записей.
Сап, аноны. Есть таблица с десятками миллионами записей и она постоянно растет. У каждой записи есть уникальный ключ (то есть уже проиндексирована). Задача: прочитать записи в таблице по уникальномым ключам. Проблема: с увеличением базы - большое время ожидания. Я вижу выход только в репликации и шардинге базы. Кэширование не поможет так как постоянно выбираются разные данные, соответственно полезно в кеш попадет мало. Что можете посоветовать?
>>1928516 Нужно понять как делается выборка из таблицы. Она же имеет какую-то логику кроме ключей? Или ты всегда только с ключом работаешь? Например у меня есть таблица с лярдом записей, но я даю пользователю за раз получить записи только за период в 30 дней + ключ. Работает стабильно. В общем я бы подумал над логикой и архитектурой в первую очередь.
Сап базач. Есть таблица в мускуле. В таблице история финансовых транзакций. Задача: найти для каждого пользователя транзакцию с наибольшей суммой. Сейчас сделано так: делается select max(debit) as maxDebit group by customer, maxDebit, потом таблица джойнится сама на себя с условием on debit = maxDebit and t1.customer = t2.customer. В общем эта залупа как-то работала, пока в один прекрасный день не пришло 6 лямов транзакций. Запрос благополучно сложился. Есть какой-то адекватный способ решить проблему кроме как джойнить таблицу саму на себя?
Сосоны, я нихуя не понял внешний ключ. Допустим, есть две таблицы. В одной таблице банковские счета, а в другой - счета рублевые и счета валютные. В первой таблице в одном столбце все счета - и рублевые, и валютные, во второй каждый тип счёта в своём столбце. Если говорить на языке теории множеств, я правильно понимаю, что внешний ключ это подмножество (валютный или рублёвый счёт) некоторого множества (все счета), и в общем-то это отношение и является внешним ключом, где внешний ключ содержит не все строки, относящиеся к основному множеству? Нихуя не могу найти нигде толкование такой ситуации, а всякие многие ко многим и один ко многим это не то.
>>1929161 Ну пикрелейтед короче. И я не понимаю, правильно ли я понял концепцию первичного ключа и внешнего ключа. Первичный ключ - все счета. У первичного ключа нет повторяющихся значений. Внешние ключи - валютный и рублёвый счёт. Внешний ключ это подмножество первичного ключа, то есть внешний ключ <= первичный ключ. Грубо говоря, во внешнем ключе есть НУЛЛЫ по отношению к первичному. Всё так? Мне надо, чтоб во второй таблице типы счетов при суммировании составляли весь столбец счетов.
Сап базач. Нужна архитектурная помощь неофиту. Вопрос платиновый - есть декстопное приложение для прохождения тестов. У нее есть локальный (файл) sqlite. В бд есть n таблиц ответов на тесты (разная логика) по типу testNQuestions, у теста есть n вопросов, нужно реализовать "сохранение" теста при прохождении если по каким-то причинам приложение будет неожиданно закрыто. В базе уже есть таблица с результатами (testNAnswers), только они сохраняются в конце теста. Я хочу переписать так чтобы запись с ответами апдейтилась после каждого вопроса. В таблице ответов есть одно поле - перечисление ответов, туда запихивается сериализируемый байт массив ответов у которого 2 поля - id вопроса и ответ (не записывать результаты у меня таки хватило ума). Дальше у меня начинаются вопросы. При загрузке теста нужно определить есть ли запись или нужно начинать новый тест. В начале я подумал что нужно доставать тот лист и смотреть сходятся ли каунт листа и каунт вопросов, но это мне не совсем подходит. Дальше я подумал что мне нужно добавить флаг - пройден ли тест, но добавить поле в таблицу не совсем правильно т.к. у меня шифрование/безопасность и юзверь может залезть в файл бд и поменять флаг. Дальше я подумал что нужно этот флаг засунуть в само поле ответов, но это как-то тоже вроде криво. А - еще есть нюанс что порядок вопросов рандомно мешается и это тоже нужно записывать чтобы потом все восстановить.
Короче пока вот что я придумал - в таблице testNAnswers я добавляю поле shuffled в котором будет массив Id вопросов (рандомный их порядок), при каждом ответе в тесте будет обновляться поле массив с ответами Answers и обновляться поле Shuffled с удаленным индексом с начала. И будет таблица типа Session в которой будет храниться user id и массив строк с тестами который юзер не прошел, который будет обновляться после каждого пройденого теста удалением строки теста. Есть какая-то более нормальная реализация этого?
>>1929150 > на языке теории множеств Это термин чисто из теории реляционных бд, врядли его можно просто выразить через теорию множеств. По сути внешний ключ это способ задания функции, тоесть благодаря внешнему ключу ты ставишь в соотвествие каждому кортежу одного отношения (строка таблицы) какой-то кортеж из другого отношения (строка таблицы) тоесть у тебя получается множество пар строк из двух таблиц, тоесть функция. В классической математике требуется взаимнооднозначное соотвествие (чего в бд нет), но в теории множеств вроде такого не надо. Но при этом сам внешний ключ это не функция. Но с помощью него задается. Нормально это не назвать, хотя может я не знаю - я в математике в общем-то нуль.
>>1929196 Зависит от того хочешь ли ты делать бизнес-логику в бд или нет. Если нет то приложение просто после каждого ответа отдает сериализованый массив ответов базе. А при загрузке база просто отдает сериализированый массив ответов назад, а приложение уже ебется что дальше делать. Например смотрит какие вопросы еще небыли заданы и задает рандомный из незаданых. А если незаданых нет - показывает результаты теста и предлагает начать новый. А если хочешь логику в бд то там скорее всего нужно обмазываться разными триггерами и обработками, вряди ты это чисто на отношениях нормально сделаешь.
Думаю добавлять несколько колонок в уже существующую таблицу в кликхаузе иди заделать новую таблицу и отбирать данные через join-ы. Они в кликхаузе сильно влияют на производительность при чтении?
Аноны пытаюсь сделать следующее: Внутри процедуры сначала положить данные во временную таблицу, а потом использовать эту таблицу в мердже. Код примерно такой
src as ( select from hui )
select into #zalupa from src
merge dst as d
Так вот, мне надаёт это сделать подчёркивает таблицу назначения(dst), хотя если убрать финт с временной таблицей вставляет нормально. Там где-то запятых или ещё чего надо нахуярить перед мерджем?
Сап аноны. Есть таблица с расписанием. Переодически в неё добавляются новые отрезки, сложность в том что они могут пересекаться.
Например добавили первый отрезок 8:00-12:00 Hui, потом добавляем ещё один, 9:00-13:00 Govno, тогда в таблице должно быть 8:00-9:00 Hui и 9:00-13:00 Govno. В какую сторону копать?
1. Схемы. Раньше работал с постгресом и mssql, там были схемы public и dbo соотв. по-умолчанию. Шо в оракле по-умолчанию? Если я зашел под юзером USER, он всё пилит в схеме USER. Это нормально? Или надо в каком-нибудь PUBLIC всё делать? Или отдельную схему создавать?
2. Авторизация. В pg и ms мне были нужны хост+порт+логин+пароль+имя_бд, и всё это влезало в какой-нибудь connection string для шарпов, которую я мог пробросить через переменную окружения. В оракле тут какие-то TNS, какие-то wallet'ы с сертификатами, но их мало, есть ещё и логин+пароль. Как вообще этим пользоваться при деплое приложения? Складывать tnsnames.ora и wallet рядом с приложением, и в connection string прописывать путь к этим файлам и логин+пароль, или есть более грамотные способы? Хотет тоже передавать все координаты БД через env vars.
Посоветуй вообще оракло-гайд для не-совсем-нубов.
Я вообще больше application guy, чем database guy, но польстился на 2 халявных виртуалки и 2 халявных 20Гб БД в oracle-cloud. И чот всё резко непонятно стало.
>>1934867 >Просто упущенно ключевое слово AS. Такое допустимо Хм, а зачем в данном случае тут AS вообще, ведь выборка лишь из одной таблицы? И почему-то для CustomProperties.City принудительно указано Nodes.
Возможно ли из MySQL запросом получить даты, сгруппированные по минутам или часам со средними значениями за это время, независимо от того, есть ли вообще или сколько строк попадает в каждый интервал? Помогите запросом. В постгресе вроде есть date_trunc, а вот в mysql - хз.
Что лучше, select join join WHERE(и какой-то where)
Или сделать через подзапросы, где изначально выдаются те которые подходят под where
А дальше идет джойн уже?
То есть SELECT from table1 t1 JOIN ON /// JOIN ON /// WHERE(long expression)
ИЛИ
SELECT ticket. , ticketupdate.updatetime FROM (SELECT * FROM ticket WHERE status = 'Open') AS ticket LEFT JOIN ticketupdate ON ticketupdate.ticketid = ticket.ticketid
SELECT from table1 t1 JOIN ON /// and status='Open' JOIN ON ///
Если в двух словах, есть нюанс с фильтрами, если фильтруишьт при джоине, значения вобще непопадают в результирующую, а если в WHERE, то попадют но будут отфильтрованы. Какзалось бы однохуйственно, но при left джоине разница будет.
Здарова базаны. Я - мимозалётный тостер, нихуя не админ В теории, есть запрос в pg где к очень дохуя строк делается джоин и от этого становится хуево всем вокрут. Вопрос - можно ли разбить список с дохуя строк на мелкие бакеты и циклом всё это переджоинить? Или это вообще больная идея?
>>1937204 Теоритически да, можешь добавить в теории партицию, написать процедурку, куда ты будешь передавать инкремент цикла. И джойнить их по одной партиции, но это довольно странная для оптимизации запросов х-ня. Лучше индексы добавь к джойнищимся таблицам.
Проблема не в EF, если что, а в том, что JOIN -- синтаксический сахарок для декартова произведения множеств, если я не всё ещё забыл со времен студенчества. Много джойнов -- пиздец, и надо либо денормализовывать данные, либо обкладывать всё костылями.
Привет, посоны. Какие вакансии предполагают 300к/наносек и что учить? Если серьезно, то хочется всерьёз углубиться в базы данных и интересно, каков срез рыночка на данный момент, что наиболее востребовано и какие знания нужны. Буду благодарен за советы.
>>1937707 У нас на тестовом контуре пару месяцев назад сервис весь постгрес сожрал, когда мы на отъебись ещё три джойна докинули. Я бы особо и не выёбывался, если бы это не случилось. Я бы даже не знал об этой проблеме, в принципе.
Аноны, дамп базы данных весом 2.5 гб импортируется уже часа 4. Это же не нормально, да? Что в конфиге нужно править чтобы ускорить процесс? В наличии 16 гб оперативки.
Скажите, а лепить флаги в int поле и проверять их битовыми операциями - это распространенная практика в системах, где логика в БД? Почему я больше нигде такого говна не видел? Ухх сука, уебал бы нахуй.
>>1939066 тригер лучше сделать before или after? я сделал сначала before и проблема появилась, если я делаю два абсолютно одинаковых инсерта и у меня имеется там уникальное поле, то оно не дает заинсертить поля, но инкремент все равно прибавляется.
>>1939144 Перед инсертом ты можешь напрямую установить значение, оно ещё не ушло в таблицу, после инсерта уже придётся апдейтить, так что лучше перед, обычно так и делают. В том, что инкремент прибавился даже после ошибки, ничего страшного нет. главное, что ты получишь уникальное значение первичного ключа.
>>1939130 Да, это нормально. Но для меня тоже дико. На сколько я понял, это какой-то олдскульный подход. И люди его использующие, очень высокого мнения о себе. Сейчас не так актуально
>>1939144 Еще у embedded'ов и системщиков часто бывает, и для всяких бинарных сетевых протоколов. Прост в сях, плюсах и современных языках общего назначения этим удобно пользоваться, а в sql - нет. >>1939276 На больших объемах данных вполне актуально.
>>1939330 Да мне похуй на машинное время. Давай тебе вместо горсти флагов is-чо-нибудь-там дадим одно поле flag и попробуй без документации понять, что в нем хранится.
У меня база nosql(mongodb), но думаю тут так же как в sql. Нубский вопрос: в базе данных есть составной индекс по полям field1+field2. Других индексов для этой таблицы нет. Если я хочу найти в ней что-то и отсортировать по field2, этот индекс хоть немного ускорит дело, или вообще бесполезен?
>>1939757 Не так, как с индексом по одному полю, но ускорит. Можешь план запросов посмотреть и убедиться, что там будет index full scan, а не table full scan. Хотя тут еще зависит от объема данных, анализатор может забить хуй на индекс, если так будет быстрее. Но я даун, лучше тебе подождать ответа крутанов.
Мне нужно собрать из разных баз данных с разной структурой данные в одну единую БД. Исходные БД - это несколько БД на MS SQL Server, а также несколько файлов Access и SQLite. Сначала я все нужные таблицы скачиваю с серверов как есть в файлы SQLite (для этого написал на C# утилитку, тут всё работает как надо), ну и локальные файлы прочих БД тоже в SQLite перегоняю. Затем я пытаюсь собрать всё это в единый файл SQLite. Для этого я подключаю все SQLite файлы в один проект и пишу один большой SQL скрипт, который переводит все исходники к моей единой структуре. Этот запрос я пишу в Notepad++. Поскольку скрипт большой и уже стал довольно сложным, мне хочется его рефакторнуть. Есть ли какой-то редактор запросов SQLite, где я могу делать переименование имён таблиц, полей и т.п. Но не просто тупой поиск и замена, а с понимаем того, что переименовываются только имена в связанных запросах и таблицах. Это есть в Visual Studio, но он понимает какой-то специфический диалект U-SQL, который отличен от SQL в SQLite. А когда Visual Studio детектит ошибку, функция переименования отключается. Что посоветуете?
>>1939130 Часто это очень удобно, а также однозначно повышение производительности и снижение размера БД. Ключевое тут обеспечить документируемость. Потому что даже самому через пол года будет сложно разобраться, что ты там в битовых операциях городишь без норм. описания. Я обычно флаговые поля помечаю в названии словом Flag и делаю табличку отдельную где каждое отдельное значение флага хранится и его название текстом. Иногда делаю табличку с полным перебором возможных флагов и внешний ключ на неё.
как лучше сделать для обуви внешний ключ? получается если артикул одинаковый, а размер разные, то это две разные записи в таблице. если я сделаю составной внешний ключ (артикул, размер) это нормально будет работать?
>>1940265 Cочетанию артикула и размера можно присвоить свой ID, и хранить сочетания в ещё одной табличке. Артикул должен быть в отдельной таблице артикулов. Текстовое поле не должны быть PK. Размер должен быть в отдельной таблице размеров. Размер может быть дробным, может быть в разных ЕИ. Размер float*4 со значением 44.5 - плохая идея для PK. Таблица сочетаний артикула и размера имеет FK на эти две таблицы. Таблица операций (поступление, отгрузка) ссылается на таблицу сочетаний как FK.
Есть одна таблица. ЕОТ В ней есть ID и есть ParentID, который может содержать значение из поля ID этой таблицы, либо NULL, если родителя нет. Я хочу для каждой записи прописать RootID, который будет равен либо просто ID, если у записи нет ParentID, либо же самый верхний parent. Как это сделать запросом SQL?
ребят, подскажите пожалуйста, как сделать чтобы при вставке одного поля, из других таблиц подтягивались нужные мне данные в эту таблицу, естественно они связаны по ключам
>>1944285 update ... set ... where уникальное поле редактируемой бд in (select уникальное поле редактируемой бд from подзапрос). Вроде это должно выглядеть так.
Всем доброго времени бытия. Вопрос к анонам: что нужно читать, знать и понимать, чтобы стать невьебенным DBA? Сейчас пишу запросы на постгресе за средний прайс, но хочется больше монет. Хватит ли мне прочитать талмуды из ОП-поста? И как отточить эти знания на практике?
Посоветуйте книгу для обучения для ньюфага. В 2013-2016 годах на VS FoxPro создавал БД в визуально стиле, но понимаю что это явно не то и не совсем полноценная БД получается, но мне в принципе нравилось. А сейчас понимаю, что надо расти дальше и просто запросов с селектами явно не хватает.
Ньюфаг итт. Возможно ли управлять схемой базы postgres через файл, синхронизировать её с файлом? То есть у меня есть например файл в котором все мои CREATE TABLE со всеми связями, и я редактирую этот файл, а база сама под него подстраивается безо всяких альтеров. Это вообще имеет смысл, или влажные фантазии макаки-меня? Сложно просто воспринимать SQL после традиционного программирования, ты в эту хуйню скармливаешь код, и он пропадает навсегда. Хочется иметь кодовую базу, которая будет определять твою БД.
>>1946818 Это не имеет особого смысла. СУБД не может догадаться, как мигриррвать уже существующие в ней данные. Не удалять же всё при каждом изменении схемы. В реальных проектах команды не вводят в консоль руками, вместо этого пишут скрипты миграции с кучей альтеров, и ничего не пропадает. Скрипты хранятся всегда и никуда не деваются, у них есть версионирование и прочее. Делают это всё разными тулзами, например, в джаве популярны flyway и liquidbase, в твоём языке должно быть что-то аналогичное.
>>1946818 Гугли <dbms name> schema compare. Для pgsql не пользовался, но для sql server'а есть ssdt schema compare в visual studio - может сравнивать 2 бд, 2 набора скриптов или бд и набор скриптов. Из разницы генерит скрипт, который можно накатить на бд чтоб устранить различия, или добавить в миграции. Есть аналогичные штуки от redgate, devart и altova (для разных субд, в т.ч. постгрес). Некоторые из этих тулов можно запускать из консоши без ui, для всяких ci/cd нужд.
>>1946825 >>1946868 Вот эти тулы и генерят скрипты миграции, который потом можно накатывать ликвибейсами, флайвеями и флюентмиграторами.
>>1946825 >>1946940 > миграции Спасибо, аноны. Погуглил, именно то что нужно: весь дефенишон базы хранится в файлах, его можно переносить на разные компы и поднимать/опускать сколько хочешь. Чаю. Думал миграции это только с одной СУБД на другую, или с языка на язык, или другую версию языка, всё такое.
Сап, двач. Пользовались ли вы GraphQL? Выглядит удобно, но знакомый сказал, синтаксический анализатор запросов работает дольше чем выполнение запросов. Может у вас был другой опыт, поделитесь
Хай, аноны. Нужно создать мелкую БД в онлайне, к которой можно обращаться с запросами, потому что в голове отрисовывать результат запроса вообще не хочется. На каком ресурсе можно сделать такое?
>>1948711 Что настраивать? Скачать установщик и нажать next? Тебе не нужен какой-то сложный сервер. Скачай MySQL и установи. Делов на 5 минут. Настроек минимум.
Сап уважаемые Пилю бд для онлайн магазина (пикрил схема) Надо запилить таблицу с оформленными заказами. Как это лучше сделать? Чтоб разные заказы от одного пользователя не путались
>>1949150 Оставь в carts только id и user_id, создай cart_items с остальными полями и cart_id. В categories поле is_parent, скорее всего, не нужно. В users не нужен user_id, только id. Ну а в таблице заказов orders ссылка на cart. И поле users либо в carts, либо в orders.
>В categories поле is_parent, скорее всего, не нужно. это я сделал чтоб понимать, какие категории содержат подкатегории, а какие содержат товары >В users не нужен user_id, только id. это специфика для чат-бота
Суп. Используются ли в реальном мире связи между таблицами не по айдишникам? Например связывают ли cities и weather по city, который тупо строка с названием города, как вот здесь https://www.postgresql.org/docs/8.3/tutorial-fk.html? По-моему хуйня какая-то.
>>1949570 Иногда бывает, например когда после групбая нужно показать сразу читаемые данные, чтоб повторно не джоинить справочники. Ну это хуйня и костыли офк.
SELECT ISNULL(( SELECT CAST(CAST(cs.ErrorMessage AS nvarchar(max)) AS XML), CAST(CAST(cs.ComponentStatisticData AS nvarchar(max)) AS XML) FROM APM_Component c JOIN APM_CurrentComponentStatus ccs ON c.ID = ccs.ComponentID JOIN APM_CurrentStatistics cs ON c.ID = cs.ComponentID WHERE ccs.ApplicationID = 666 AND c.ShortName like '%FUUU%' FOR XML PATH('')),('None'))
Пик на случай, если вакаба сожрет форматирование. Это MSSQL. Софтина утверждает, что Incorrect syntax near ')'. Ебусь несколько часов. Видимо, я слепой нахуй.
>>1950924 У тебя открывающих скобок 10, закрывающих 12. Понаберут по обьевбляние дибилов блядь, которые уже даже в спизженном коде скобки не могут проставить.
Любое IDE может показывать пару скобоку, ты что совсем долбаёб?
Доброго времени суток аноны. Помогите пожалуйста решить одну задачу новичку. Пикрил схема Как лучше всего получать order, имея user_id? Можно как-то сделать это одним запросом? Или нужно джойнить carts и orders?
Есть один sqlite дб файл в локалке и есть 2 программы которые к нему подключатся. Если они начинают делать почти синхронно запросы на запись то обе фризятся до условного таймаута. Это можно как-то пофиксить? inb4: >ставь sql сервер Мне нужно чтобы этот дб файл юзверь мог условно скачать и работать с моим приложением без йоба инструкций с поднятием sql сервера. И да, в то же время мне нужно чтобы с бд файлом могли работать множество пользователей. Пока что думаю вынести логику в общий файл в ридонли, а то что идет на запись - создавать локальную бд. Благо что-то записывать в общую бд нужды пока что нету.
Cап, двач. Нужно писать в бд много и параллельно, ждать результата не нужно. Есть какие-то очереди реквестов на инсерт, типа отправил - забыл, чтобы СУБД сама очередь делала и писала по возможности? Или что-то другое использовать для очереди, тогда что именно?
>>1953127 еще вопрос,допустим у меня слишком много юзеров. я захожу в панель управления и и хочу видеть только активные заказы в этой куче мале? в таблице юзер делать колонку со статусом(в процессе или доставлено) а потом просто в хтмл делать сортировку этой колонки(наверху доп в процессе)?
>>1953136 Статус нужно делать в orders, если сделать в users, один пользователь не сможет сделать за раз больше одного заказа. Да и костыльно как-то. Сделай джойн users и orders по users.id = orders.user_id и добавь индекс для orders на колонки user_id и status.
>>1953208 Когда надо несколько значений можно выбрать один из вариантов: 1. Сделать на каждую цифру колонку. Но тогда таблица может быстро вырасти 2. Записать как строку. Но понятно, что по одной какой-то цифре искать нельзя будет нормально. (можно, но это пиздец) 3. Кодировать бинарно числа в одно. В общем зависит от контекста задачи.
Сап /b /pr, скорее всего скоро придется завалиться на проект, где будет дохуя низкоуровневой ебли с базами данных (прям хардкор, писать оптимизаторы sql запросов, патчить PostgreSQL и всякие такие штуки), но проблема в том, что я нихуя не знаю как работают, и как они устроены внутри (буквально на выходных прочел и написал Btree), даже сам SQL хуево знаю. Собсна вопрос - есть ли какие-то книги, которые описывают как бд работают изнутри? (желательно с кодом и не особо старые).
Народ, а можно ли взаимодействовать с Postgres, не держа с ней постоянных соединений, а, скажем, с каждым запросом слать некий token, который бы содержал инфу об авторизации? Чё-то не гуглится пока ничего на эту тему.
>>1955496 Хочу написать лямбды (Next.js), которые будут слать запросы к Postgres. Проблема в том, что одновременно выполняемых лямбд (и, как следствие, соединений с базой) может быть много. Ну и создавать каждый раз в лямбде клиента для Postgres (и ждать, пока установится соединение) только чтобы отослать через него 1 или несколько запросов - это нехорошо. Можно, конечно, написать и работать через отдельную прослойку, которая будет держать постоянные соединения с Postgres, с авторизацией по токенам, но я думал, может, Postgres уже сама что-то такое умеет.
Существуют ли какие-нибудь семантические подходы, которые позволяют писать SQL запросы коротко, оптимально и производительно. WITH makers as ( SELECT maker, model, count(model) over (partition by maker) count_model, type FROM Product ) , lapt as ( SELECT maker, COUNT(DISTINCT l.model) count_laptop, 'Laptop' as type FROM ( SELECT model FROM laptop UNION SELECT model FROM Product WHERE Type = 'Laptop' ) l INNER JOIN Product p ON l.model = p.model group by p.maker ) , PC_mod as ( SELECT maker, COUNT(DISTINCT p.model) count_pc, 'PC' as type FROM ( SELECT model FROM PC UNION SELECT model FROM Product WHERE Type = 'PC' ) pc INNER JOIN Product p ON pc.model = p.model group by p.maker ) , Printer_mod as ( SELECT maker, COUNT(DISTINCT p.model) count_printer, 'Printer' as type FROM ( SELECT model FROM Printer UNION SELECT model FROM Product WHERE Type = 'Printer' ) pr INNER JOIN Product p ON pr.model = p.model group by p.maker )
SELECT maker, type, SUM(prc) FROM ( SELECT distinct m.maker, 'Laptop' as type, COALESCE(CAST((CAST(count_laptop AS NUMERIC(6,2))/ CAST(count_model AS NUMERIC(6,2)) 100) AS NUMERIC(6,2)), CAST(0 AS NUMERIC(6,2))) as prc FROM makers m LEFT JOIN lapt l on m.maker = l.maker and m.type = l.type
UNION ALL
SELECT distinct m.maker, 'PC', COALESCE(CAST((CAST(count_pc AS NUMERIC(6,2))/ CAST(count_model AS NUMERIC(6,2)) 100) AS NUMERIC(6,2)), CAST(0 AS NUMERIC(6,2))) as prc FROM makers m LEFT JOIN PC_mod l on m.maker = l.maker and m.type = l.type
UNION ALL
SELECT distinct m.maker, 'Printer', COALESCE(CAST((CAST(count_printer AS NUMERIC(6,2))/ CAST(count_model AS NUMERIC(6,2)) * 100) AS NUMERIC(6,2)), CAST(0 AS NUMERIC(6,2))) as prc FROM makers m LEFT JOIN Printer_mod l on m.maker = l.maker and m.type = l.type ) as a GROUP BY maker, type
>>1955637 Ты не понял. Лямбда - это новый процесс, который создаётсся для обработки каждого нового запроса (я же о serverless архитектуре говорю). И, если действовать по-старому, то для доступа к бд в каждом таком процессе нужно создавать новое соединение, которое закрывается при завершении процесса после обработки запроса. Лямбды могут запускаться на разных компах. И никакого connection pooling тут быть не может.
Что касается жс-а, то в клиенте pg этот connection pooling был изначально (с 2010 года, по-моему). Но это к слову.
Вообще да, облачные функции плохо дружат с субд, где надо поддерживать постоянные соединения. В oracle cloud дают халявные 2 бд с 20гб, и на каждую всего 20 соединений - новое создается около 30 секунд, и они быстро исчерпываются. Т.е. лучше вообще использовать какое-нибудь nosql с нативным http api.
Тупые долбоебы, что вам мешало нумеровать треды? Стоя на ёбаной развилке полчаса пытался понять в какой идти по их описанию, а оказывается это одна ветка. Свиньи блять.
Кто умеет в Microsoft SQL Server Management Studio? Задали диаграммы сделать но таблицы для них не отображаются. Я создал базу данных, создал таблицы, добавил данные. Что делать дальше я не понял. Вроде begin transaction; commit transaction; но что это по факту делает я не разобрался.
Народ, какое количество строк максимально база способна переваривать, 10м строк это много для базы? Какая по параметрам должна быть база, что бы сожрать 10 Милионов строк и выдавать их не давясь?
Изучаю sql, возникла проблемка с таким типом задачи: есть 3 таблицы (работники, пк, работник_пк). В "работниках" поля id, имя, фамилия. В "пк" id и производитель. В связующей id, id_работника и id_пк. Связь многие ко многим. Задача вывести имена работников за которыми привязано больше 2 пк. К сожалению идей нет как делать это задачу. Понимаю, что надо как-то через джоины, но дальше хз
>>1992935 SELECT e.name FROM (SELECT employee_id, count(pc_id) as cnt FROM employee_pc HAVING count(pc_id) > 2 GROUP BY employee_id) t1 LEFT JOIN employee e ON t1.employee_id=e.id
мб так можно? таблица пк даже не понадобится по идее, так как там только данные о производителе содержатся пишу с телефона и не могу прогнать запрос, но по идее может сработать)