Этого треда уже нет.
Это копия, сохраненная 10 мая 2021 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Шардинговый реплицируемый баз данных тред. Шапка Edition v1.0 /sql/ # OP 1869616 В конец треда | Веб
Новый баз данных тред, теперь с альфа-версией шапки.

Здесь мы:
- Негодуем, почему шапка - говно, и предлагаем коллективному ОПу идеи, как её улучшить.
- Разбираемся, почему PostgreSQL - не Oracle
- Пытаемся понять, зачем нужен Тырпрайс, если есть бесплатный опенсурс
- Обсуждаем, какие новые тенденции хранения данных появляются в современном цифровом обеществе
- Решаем всем тредом лабы для заплутавших студентов и задачки с sql-ex для тех, у кого завтра ПЕРВОЕ собеседование
- Анализируем, как работает поиск вконтакте
- И просто хорошо проводим время, обсирая чужой код, не раскрывая, как писать правильно

Туториалы на русском для тех, кто не умеет гуглить, не может в английский и вообще готов жрать что угодно:
SQL:
- MySQL, Postgres, SQL Server: https://metanit.com/sql/
- Синтаксис SQL кратко: https://learnxinyminutes.com/docs/ru-ru/sql-ru/
- Плейлисты по разным СУБД: https://www.youtube.com/c/SQLDeveloperBI/playlists
- Тоже плейлист, сортировка хуёвая: https://www.youtube.com/watch?v=EHvzvwAv7RU&list=PLY7PmJJFH5nT-lbFKxfbp3rw5BBuq5Azo
- https://www.youtube.com/c/SQLDeveloperBI
NoSQL:
- MongoDB: https://metanit.com/nosql/mongodb/
- Cassandra: https://proselyte.net/tutorials/cassandra/

На инглише:
SQL:
- https://www.w3schools.com/sql/

Литература:
- Прибыл Фейерштейн. Oracle PL/SQL. Для профессионалов - если уметь исказть, можно найти бесплатно без СМС и на русском.
- Алан Бьюли. Изучаем SQL. - про MySQL, тоже легко находится. Довольно старая, но базовые вещи не сильно меняются.
- К. Дж. Дейт. Введение в системы баз данных - талмуд на овер 1000 страниц.
- Томас Кайт. Oracle для профессионалов - тоже талмуд.

Задачки для оттачивания sql-скилов:
- https://www.sql-ex.ru
- http://sql-tutorial.ru/
- https://www.codewars.com/?language=sql

ETL, OLAP, DWH и другие умные слова:
- https://www.youtube.com/watch?v=WPZuzDJXs-Q&list=PLhhjwMYxzolhP29LSPPwORVQxJX5OjYix
- OLAP DAX Power BI: https://www.youtube.com/playlist?list=PLhhjwMYxzolhXuySjLR2_n-xb6VvWnjju

Прочее:
- https://dbdb.io/
- https://db.cs.cmu.edu/
- https://www.youtube.com/channel/UCHnBsf2rH-K7pn09rb3qvkA/playlists
- Сравнение диалектов SQL: http://troels.arvin.dk/db/rdbms/
- Как БД работают изнутри: https://habr.com/ru/company/mailru/blog/266811/

FAQ:
Q: Нужно ли знать английский?
A: Да.

Q: Что лучше, SQL или NoSQL?
A: Как обычно, зависит от задач. Нужна любой ценой скорость - бери NoSQL, нужна согласованность данных - SQL. У всего свои плюсы и минусы, и в обозримом будущем ни один подход не заменит другой полностью.

Q: Вопросы с лабами и задачками
A: Смело спрашивай, с вероятностью больше 50% ответят, но могут и обоссать. на Дваче все твои друзья

Предыдущий тред тонет здесь: >>1781628 (OP)
screenshot-2020-11-30-11-06-12.png65 Кб, 1335x434
2 1869628
Уже больше двух лет пытаюсь начать задания на sql-ex.ru
Каждый раз когда перехожу по ссылке даже если ссылка работала у человека чье задание пытаюсь разобрать у меня показывает пикрил
Что я делаю не так?
3 1869631
>>1869628
www и без это разные домены. Скоре всего дело в этом.
SAGE 4 1869644
Шапка говно, книги говно. Объявляю тред нелегетимным. Сажи перекатчику дебилу.
sage 5 1869645
sage 6 1869647
sage
sage 7 1869650
sage
изображение.png12 Кб, 698x420
sage 8 1869652
image.jpg27 Кб, 512x548
9 1869658
Хз норм помоему
Сделайте тред в любом случае по бд пожалуйста нужно срочно вкатиться в пж буду срать
10 1869660
>>1869658
В анус себе вкатись, псина, область и так уже полудохлая.
11 1869663
>>1869660
Какая область?
12 1869664
>>1869663
Почти вся, что связана с БД.
image.jpg28 Кб, 640x480
13 1869675
>>1869664
Пьяный что ли?
14 1869676
>>1869675
Аргументы?
15 1869679
>>1869676
У тебя за щекой, проверяй.
16 1869683
>>1869676
У тебя куда-то весь веб пропасть успел?
В смысле область бд полудохлая?
17 1869688
Ради интереса глянул, на HH куча чистых вакансий Oracle PL/SQL и MS SQL.

Есть чистое SQL программирование?

Туда вкатываются, легко берут со стороны?
18 1869702
>>1869688
С MS SQL ты по определению должен будешь взаимодействовать с пачокй МСовского софта включая MS Windows Server, MSQL Server (Углубленно мочь в HA и DR) + MSQL Server Managment Studio (Углублённо мочь T-SQL), плюс ориентироваться в Азурных сервисах
С ораклом тоже самое, только азур вместо редшифта и дальше пак маст хев аналогичного софта

Мочь в программирование ориентируясь в паттернах тоже нужно, как и уметь CDшить хотя бы БД

Конкретно эти две бд еще та анальная галера на любителя
мимо на диване где-то прочитал в интернете
19 1869752
Аноны, посоветуйте, плиз, нубу DBMS по юз-кейсам.
В одну таблицу (коллекцию) в базе каждый месяц будет добавляться по несколько десятков тысяч записей (примерно 350к за год). Нужно иметь возможность организовать пагинацию по этим записям с фильтрацией по критериям (полнотекстовый поиск по нескольким полям), сортировкой (дата создания или другое поле с числом) и быстрым доступом к произвольным страницам. Записи после добавления в базу почти наверняка изменяться не будут.
Как фронт-энд макакен я сразу стал читать про монгу. Но, чем больше я про неё узнаю, тем больше у меня складывается впечатление, что от неё нужно держаться подальше. В частности, с пагинацией у монги хреново - чем больше документов в коллекции, тем больше будет тормозить получение "дальних" страниц.

Что из бесплатных DBMS выбрать под такие нужды?
изображение.png34 Кб, 285x177
20 1869798
Аноны помогите разобраться с merge.

Пробую мержить, но постоянно вставляет новую строчку с последней датой. Чото не могу понять как это работает.

Таблица

Дата-Поле1-Поле2

вторая аналогичная, смотрим по дате, если записи нет вставляем новую, если запись есть такой датой уже есть но несопадает одно из полей, обновляем.

Код
https://pastebin.com/2XSAQLeq
2020-03-08 13.25.12.jpg133 Кб, 1080x1080
21 1870358
Внимание! Срочно поделитесь опытом использования dynamo db!
22 1870365
>>1870358
Кей-валуе специфик носкуль же, какой опыт может быть?
23 1870572
>>1870365

>Кей-валуе


Очевидно ты туда даже не заглядывал. Это тебе не редис. Есть особенности моделирования реляционных данных, выбора праймари и сортинг ключей, аксесс паттернов, учёт ограничений на дёрганье партишенов. Динамо безусловно лучшее масштабируемое решение на рынке
24 1870577
>>1870572
Всё так.
25 1870578
>>1869752

>нубу


postgresql

там есть всё что тебе нужно искаропки если сумеешь создать пользователя :cf:
26 1870610
>>1869616 (OP)

>Q: Что лучше, SQL или NoSQL?


>A: Как обычно, зависит от задач. Нужна любой ценой скорость - бери NoSQL, нужна согласованность данных - SQL.



ну тоись если тебе нужны ебанутые бредовые результаты,
но быстро,
то бери NoSQL

зато хипстеры будут в губы целовать
27 1870628
Кстати чем из nosql визуализируют данные обычно?
28 1870683
>>1870610

> если тебе нужны ебанутые бредовые результаты,


> но быстро,


> то бери NoSQL


Всё же можно придумать несколько юзкейсов, когда частичная или полная потеря данных некритична. Какой-нибудь кеш на редисе, который будет in-memory, собирается заново при перезапуске сервера. Что-нибудь по-быстрому посчитать в какой-нибудь бигдате, используя БД как промежуточное хранилище расчётов без дальнейшего хранения. По-быстрому высрать продукт с коротким временем жизни и не требующим поддержки - это как языки с динамической типизацией, где можно по-быстрому получить хоть и хуёвый и нестабильный, но результат.
29 1870685
>>1869675
Я бы ещё выпил!
30 1871498
>>1870683

например результаты голосования
31 1871635
>>1870610
Ну для какой-нибудь синхронизации тудушки на нескольких мобилках самое то
Когда у тебя один таск может расшариться с одного девайса на 2 других, на втором модифицироваться и на третьем удалиться будучи неподключенным к интернетам ты на склах адекватно это не реализуешь в принципе
32 1871676
>>1871635
Данные активной сессии можно хранить там, что бы в базу не лазить
33 1871820
Относительно недавно работаю в финтех области(больше уклоном в фин), думал подучить в свободное время sql, но глянул вакансии по ключевому слову sql - требуются одни программисты. Стоит ли вообще заморачиваться этим не прогерам?
34 1871827
>>1869616 (OP)
Читал эту мангу, по базам не очень, математические поинтереснее.
>>1869688
Нет, это грязное SQL-программирование на процедурных языках с элементами ООП, требующее знания возможностей базы далеко за пределами CRUD.

В частности pl/sql - это часто программирование ETL-операций на диалекте паскаля, реже написание хранимок скрывающих сложную структуру данных.
35 1871837
>>1871820
разумнее прокачиваться в тех направлениях, которые тебе в проф. деятельности помогут, разве нет?

если тебе не нужен скл, то и фиг с ним
myisamtoinnodbfreespace.jpg28 Кб, 817x575
36 1872697
Перевел в mysql myisam в innodb. Ну ахуеть теперь!
Может стоило остаться ?
или попробовать вместо utf8mb4 utf8bin ?

Ну и запросы немного разъехались тоже.
37 1872708
>>1870610

>ебанутые бредовые результаты


Eventual consistency, которая, как правило, имеет место у NoSQL DBMS, на 100% подходит для записи всего, что происходит один раз: история изменений цен на акции/курсы валют, история финансовых операций, история поведения пользователя и т.п.. Т. е. применений у NoSQL не так уж и мало.
Потом конкретно у DynamoDB есть возможность делать strongly consistent reads - операции чтения, гарантированно возвращающие последнее значение полей записи в рамках одной зоны. В зонах, как правило, несколько локаций, и неважно, из какой локации писали в базу/читают из базы.
38 1873100
какие есть места куда берут только с sql?
39 1873135
>>1873100
Профессия так и называется SQL Engineer
Но очевидно по своей узкой специализации на джуна нужны знания на уровне знаний лоу сениора веб-макакена
40 1873294
>>1873100
SQL аналитик
41 1873311
Поясните за оптимизацию AND в поиске

Допустим я хочу что бы у меня искало по двум полям, но максимально быстро при этом.

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сек
42 1873722
>>1873311
а хуй его знает, почитай про 'Partial Index', сверху можно докинуть индекс на контролькую сумму строки (чтобы не по строкам индексировать/искать) и/или через any в массивах изъебнуться.
43 1873733
>>1873311
Порой сильно мешает эта хуйня, что порядок вычисления частей AND и OR в оракле не гарантирован, как в обычных языках программирования. Несколько раз проёбывался из-за того, что в правой части AND вызывается функция, которая кидает исключение, когда проверка в левой части даёт False, и если бы порядок гарантировался, исключение не кинулось бы никогда. Приходится из-за этого городить костыли с CASE WHEN.
44 1874761
Поясните, в чём отличие процедуры от функция, кроме того что функция не умеет INSERT/UPDATE, но может использоваться SELECT. В каких случаях нужно использовать первой, в каких второе офк кроме очевидных ситуаций которое попадают под ограничения?
45 1874862
>>1870610
Еще не рекомендую автомобили. Да быстро. Но можно умереть. И кто то даже умрет. Оно того не стоит. Ногами лучше.
sage 46 1874887
>>1873100
в дурку
47 1874892
>>1874862
Да, автобляди соснули
48 1875201
А работал кто с MySql через MATLAB?
И может кто подскажет: как я понимаю реляционная база данных-это большая такая таблица, которая имеет связи с другими таблицами. И есть ли какие-то конструкторы БД? Чтобы как-то графически сделать макет базы данных, а потом уже начать ее кодить/заполнять? Просто сейчас у меня на ум приходит сделать только две таблицы, но со временем БД надо будет расширять.
И что лучше MySQL или MS SQL?
49 1875208
>>1875201

>как я понимаю реляционная база данных-это большая такая таблица


Нет

>И есть ли какие-то конструкторы БД?


Какие-то гушные инструменты были, что то подобие конструктора

>И что лучше MySQL или MS SQL?


Если у тебя ничего сложного не будет, то бери что знаешь. Если будет - советую посмотреть в сторону постргреса
50 1875232
>>1875201
Хосспаде, выгрузи csv и поработай в матлабе. Обязательно оперативность из матлаба нужна?
51 1875353
А какой нынче бекап mysql не мудацкий?
Есть ли наиболее полный и популярный скрипт?
и желательно чтобы без qpress.

мне нужны инкрементальные и полные бекапы, но не хочу опять на шелле постоянно все городить. я устал :(
52 1875371
>>1869616 (OP)
Хосспаде. Неужели шапку сделали! Наканец-та пора учить SQL. На работу сука не берут без него.
53 1876109
Анон, без sql не берут на работу.
Можешь плез посоветовать самый быстрый способ набить такой минимум с которым не стыдно будет проходить собеседования?
54 1876114
>>1875371
>>1876109
куда вы все устраиваетесь, что везде нужен скл?
55 1876117
>>1876114
Да это оба моих сообщения. Забыл что вчера примерно тоже писал.
Ну вообще везде, где есть бэкенд. Пишу на пщ и петухоне. На каждом собесе спрашивают про sql. А я то хули, когда писал на питоне пользовался орм, а когда на го - были свои БДшеры.

Так и не выучил. Хуй получается работу поменять.
56 1876132
>>1876109
Если идёшь на простого разраба, а не БДшника, то там и учить-то почти нечего, за пару недель можно управиться.
Берёшь какой-нибудь хуёвый гайд ( https://metanit.com/sql ) или плейлист на ютубе. Смотришь, запоминаешь про создание/изменение таблиц, первичные/внешние ключи, инсерты, апдейты, делиты, селекты с типами джойнов и подзапросами. Прорешиваешь задачи ( https://www.sql-ex.ru ). Но прям все задрачивать не надо. Придумываешь схему БД для какого-нибудь книжного магазина или для социалочки, причём схема нормализована хотя бы до третьей нормальной формы. Пишешь соответствующий пет-проект без юзания ORM, тупо голыми запросами и смотря, как это принято делать в твоём языке. Всё, дальше опыт и stackoverflw.
57 1876136
>>1876132
Спасибо анонче. Жаль, что все собеседования на этой неделе. Буду грызть как могу.
полигон.jpg182 Кб, 976x1184
58 1876844
Добрый вечер, аноны.
Тут такое дело: за этот вузовский курс не было НИ ОДНОЙ, СУКА, ЛЕКЦИИ, а индивидуальное надо каким-то образом сделать. И вот, я начал с того, что нарисовал ИЛМ, в правильности которой очень сомневаюсь. Ибо тут, например, есть такой момент:

"Если не все компоненты имеются в наличии, то делает заявки на оптовые склады лекарств и фиксирует ФИО, телефон и
адрес необслуженного покупателя, чтобы сообщить ему, когда доставят нужные компоненты."


Нужно ли, если говорить о таблице "Заказ", указывать в ней ИД пациента или нет (на мой взгляд, не стоит, т.к. оно уже было указано в "Рецепт" как внешний ключ, а ИД рецепта - как внешний ключ в "Заказе")?

И вообще, аноны, что скажете по поводу нормализации, связей между таблицами и т.п.? Сойдет или нет?
59 1876917
>>1869683

> В смысле область бд полудохлая?


она не полудохлая, она, если говорить о программировании, давно и непоправимо сдохла. последние 20 лет никто, находясь в здравом уме, в новом проекте не запиливает бизнес-логику на уровне БД. осталось одно дикое легаси которое писали чуваки которым щас по 70 лет и прикладные околоадминистративные задачи.
60 1876920
Объясните что за базы данных information_schema и test в mariadb. Не могу найти информации по этой теме.
61 1876958
>>1876920

> information_schema


Гугли "словарь данных", когда поймёшь эту концепцию, станет понятно, для чего эта БД.

> test


Хз, не трогай.
62 1877095
>>1876844
Нет в заказе ненужен. Непонятно зачем таблица технология изготовления. Она должна находится не между складом, а отдельным линком либо за складом. Да и вобще лекарство это справочник, оно должно смотреть в рецепт, а технология за ней. Представь ситуацию когда лекарства нет на складе, но есть в рецепте. Вобщем погугли схему снежинка
image.png120 Кб, 226x289
63 1877527
>>1869616 (OP)
Анон, пожалуйста можешь написать скрипт для создания следуйщего тригерра

/ Object: Trigger [dbo].[TriggerAspNetUsersInsert] Script Date: 12/10/2020 8:05:02 AM /
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

ALTER TRIGGER [dbo].[TriggerAspNetUsersInsert]
ON [dbo].[AspNetUsers]
AFTER Insert
AS
BEGIN
SET NOCOUNT ON;

INSERT INTO USR_User with (rowlock)
([USR_Nazwa]
,[USR_Telefon]
,[USR_Ulica]
,[USR_Miasto]
,[USR_NumerDomu]
,[USR_NumerLokalu]
,[USR_KodPocztowy]
,[USR_NIP]
,[USR_KONID]
,[USR_AspNetUsersId]
,[USR_WaznoscUmowy]
,[USR_DataWeryfikacji]
,[USR_Komentarz]
,[USR_PoziomUprawnien])
select
'',
PhoneNumber,
'',
'',
'',
'',
'',
'',
0,
Id,
'2020.01.01',
null,
'',
0 from inserted

END
image.png120 Кб, 226x289
63 1877527
>>1869616 (OP)
Анон, пожалуйста можешь написать скрипт для создания следуйщего тригерра

/ Object: Trigger [dbo].[TriggerAspNetUsersInsert] Script Date: 12/10/2020 8:05:02 AM /
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

ALTER TRIGGER [dbo].[TriggerAspNetUsersInsert]
ON [dbo].[AspNetUsers]
AFTER Insert
AS
BEGIN
SET NOCOUNT ON;

INSERT INTO USR_User with (rowlock)
([USR_Nazwa]
,[USR_Telefon]
,[USR_Ulica]
,[USR_Miasto]
,[USR_NumerDomu]
,[USR_NumerLokalu]
,[USR_KodPocztowy]
,[USR_NIP]
,[USR_KONID]
,[USR_AspNetUsersId]
,[USR_WaznoscUmowy]
,[USR_DataWeryfikacji]
,[USR_Komentarz]
,[USR_PoziomUprawnien])
select
'',
PhoneNumber,
'',
'',
'',
'',
'',
'',
0,
Id,
'2020.01.01',
null,
'',
0 from inserted

END
64 1877546
>>1877527
Вопрос снят
image.png33 Кб, 900x579
65 1877711
Здарова пацаны
Пилю бд для онлайн магазина (вообще впервые пилю бд) и вот возник вопрос. У меня есть таблица пользователей и таблица товаров. Теперь мне нужно зафигачить корзину. Я сделал таблицу со столбцами id - user_id - product_id - amount. Но погуглив, я увидел что некоторые аноны product_id и amount выносят в отдельную и связывают их. Зачем это нужно?

Пример реализации корзины который я нашел в инете
66 1877714
И еще сразу один вопрос. Я запускаю postgresql на локалхосте через докер, но уже второй раз бд сама по себе полностью удалилась. Точнее сама бд как бы есть, но таблиц в ней нет. Полагаю что это проиходит из-за того что я нажимаю кнопочку "обновить программы" в ubuntu и она обновляет либо psql либо docker. Я прав? И как избежать этого в дальнейшем
67 1877764
>>1877711

> Goods


В магазине товары тоже не бесконечны, поэтому поле количества в ней тоже нужно.

> OrderState


Это может быть излишним, в большинстве СУБД есть поддержка enum-ок.

> OrderLine


Не понятно, зачем дублировать цену товара сюда. Разве что у тебя предполагаются какие-то наценки/комиссии, зависящие от времени,, но в таких случаях сумма скорее будет заранее подсчитана и храниться в таблице заказов, а не для каждой строки заказа отдельно.

>>1877714
Возможно, ты хранишь данные не в volume, а прямо в контейнере, и если контейнер удалится, данные пропадают и в новом контейнере не видны.
68 1877902
>>1869616 (OP)
В таблице хранятся номера телефонов как varchar, нужно найти в таблице строку с подходящим номером, но вот незадача: в базе номера лежат номера в строгом формате: начинаются с 7 (русские номера), 11 знаков, никаких скобок и дефисов; а извне может придти любой телефон, скажем начинающийся с 8. Я могу отфильтровать на бэкенде всякие дефисы и скобки, но как делать эффективный запрос в базу, чтобы найти номер несмотря на то, что он будет начинаться не с 7?
69 1877905
>>1877902
Использовать регулярку и предикат like?
70 1877936
>>1876920

>test


Какой-то мудак не дочитал мануал по команде до конца
https://mariadb.com/kb/en/mysql_install_db/#the-test-and-test_-databases

если там ничего нет, то можешь удалять.
71 1877939
>>1877936
хотя я видел "прод", где создали базу юзеров в первой попавшейся базе куда было возможно записывать.
И продолжают так работать.
10 лет.
72 1878094
>>1877902
Я тут в одном из прошлых тхредов предлагал использовать left вместо like, в итге был обоссан анонами. Вобщем like с индексмо работает довльоно быстро.
73 1878484
>>1869702
>>1869752
Запоздалый ответ:

Во - первых, будешь делать пагинацию -- ни за что не используй 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 на такое, потому что эти фреймворки очень хорошо скрывают всю сложность.

Опять - таки если используешь ORM -- следи, чтобы не было N + 1 запросов (ссылка https://stackoverflow.com/questions/97197/what-is-the-n1-selects-problem-in-orm-object-relational-mapping)

Если у тебя есть фильтры, которые могут быть задействованы только вместе (скажем пользователь выбирает фильтр x, потом у него появляется возможность выбрать фильтр y и только после этого фильтр z) --
на такие вешай составной индекс (x, y, z). Порядок колонок в определении индекса важен.
БД сможет юзать любую комбинацию (x), (x, y), (x, y, z). Но если ты отфильтруешь скажем только по y или только по z, или по y и z -- БД такой индекс не заюзает.

Для твоих целей монга не нужна совсем. 350 к записей в год при нормальном проектировании любая реляционка выдержит как нефиг делать (советую постгрес). И будет во много раз быстрее тормознутой монги.
73 1878484
>>1869702
>>1869752
Запоздалый ответ:

Во - первых, будешь делать пагинацию -- ни за что не используй 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 на такое, потому что эти фреймворки очень хорошо скрывают всю сложность.

Опять - таки если используешь ORM -- следи, чтобы не было N + 1 запросов (ссылка https://stackoverflow.com/questions/97197/what-is-the-n1-selects-problem-in-orm-object-relational-mapping)

Если у тебя есть фильтры, которые могут быть задействованы только вместе (скажем пользователь выбирает фильтр x, потом у него появляется возможность выбрать фильтр y и только после этого фильтр z) --
на такие вешай составной индекс (x, y, z). Порядок колонок в определении индекса важен.
БД сможет юзать любую комбинацию (x), (x, y), (x, y, z). Но если ты отфильтруешь скажем только по y или только по z, или по y и z -- БД такой индекс не заюзает.

Для твоих целей монга не нужна совсем. 350 к записей в год при нормальном проектировании любая реляционка выдержит как нефиг делать (советую постгрес). И будет во много раз быстрее тормознутой монги.
74 1878495
>>1878484
И еще -- если схема БД хотя бы мало-мальски сложная (что часто бывает в кровавом тырпрайзе), скажем кол-во табличек становится больше 10 -- не пожалей и раскошелься на какой - нибудь софт, позволяющий визуально осмотреть ее. Потыкать на табличку, посмотреть на связи. Плюс менять ее очень просто и в конце она генерит тебе большой запрос, создающий твою БД. Это просто незаменимая штука в подобных делах. Не реклама, но сам я пользуюсь DbSchema.

Мигрировать с такой тулзой тоже проще намного. Например в DbSchema используется обычный xml для описания проекта и ты просто меняешь схему в нем (перетаскивая мышкой таблички и стрелочки), после чего любым diff-ом сравниваешь старый xml и новый и на основе него пишешь скрипт миграции.
75 1878662
>>1869752
если тебе нужен полнотекстовый поиск то я бы делал так -
взял любую бд, постгрес например, который использовался в качестве хранения данных. и в дополнение к нему отдельно использовал бы полнотекстовый поиск, который строил бы индексы на основании данных в БД. индексы самой БД я бы не использовал, так как там начнутся сложности когда нужно бдет полнотекстовый поиск делать по нескольким таблицам сразу ну и архитектурно это смешение уровней приводящее к проблемам.

если говорить о реализации то например hibernate-search умеет такое из коробки. просто указываешь в аннотации все поля которые должны быть включены в индекс (в т.ч. коллекции или вложенные объекты) и он его тебе строит. Также есть возможность хранить данные в индексе, это приведет к тому что при поиске обращения к БД вообще не будет.

Звучит сложно но в реализации на самом деле все довольно просто и работает очень быстро.

http://hibernate.org/search/

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

https://lucene.apache.org/

база при этом вообще неважна, хоть дерби или h2 используй. она нужна только как хранилище данных если нужно будет поисковый индекс перестроить, как я уже говорил если все правильно настроить к ней запросов вообще не будет.
76 1878676
>>1878484

> Если у тебя есть фильтры, которые могут быть задействованы только вместе (скажем пользователь выбирает фильтр x, потом у него появляется возможность выбрать фильтр y и только после этого фильтр z)



это конечно хороший совет, но в реальности в больших приложениях все это нереально отследить. например сейчас в проекте над которым я работаю 150 сущностей (таблиц) у каждого из которых в среднем не меньше 10 полей. если отслеживать все комбинации полей в запросах то нужно будет строить несколько тысяч индексов, это нереально.

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

> Если есть колонка, в которой хранится CLOB или BLOB


есть мнение что файлы в БД вообще хранить некошерно и для этого нужно использовать отдельное файловое хранилище
77 1879982
>>1874862

тупая оналогия.

NoSQL это хипсторско пидорская хуйня,
для дегродов которые нисмагли в реляционную алгебру.

это примерно как Жаба с гарбаджъ коллектором,
которую придумали бля тех кто не смог Цэ Кресты
78 1879984
>>1878495

ERWin

а там глядишь и слово "нормальизация" встретицца.
79 1880062
>>1879984

> ERWin


охуеть ты некрофил

любая нормальная иде умеет таблички рисовать, но за последние лет пять лично я ни разу этим не пользовался, абсолютно бесполезная хуйня как по мне.
80 1880090
Аноны, есть Postgres, хочу запилить гео-распрелеленную систему. В сторону каких решений смотреть?
Думаю над мульт мастером, нагуглил и попробовал Bucardo, но может анон знает что-то поинтересней?
image.png7 Кб, 227x220
81 1881058
Как сделать такое в Mysql?

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

Нужно сделать такую хуйню. У пиццы 5 ингридиент, ей надо взять 0.2 (20 грамм), 0.5, 1.2, 1.6, 2 из таблицы два разных игридиентов.
Без понятия как такое провернуть.
82 1881071
>>1881058
умножение в школе еще не проходили?
sage 83 1881073
>>1881071
Сука, только зашел и уже тупорылый еблан нарисовался
84 1881075
>>1881058

>Как сделать такое в Mysql?



ХРАНИМКИ
85 1881181
>>1881073
Тупорылый еблан тут ты. Пришел с тупым вопросом и сразу шлнеш мимокрока нахуй. Сам решай свои лабы, долбаеб.
sage 86 1881185
>>1881181
Да ебальник завали хуйло, стоите друг друга, долбаебы ссаные
87 1881373
>>1881058
Попробуй умножить.
88 1881384
>>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)
)
или хранимкой.
89 1881385
>>1881384

> интгредиентах


> ingedients


> intedient


У меня кстати половина кнопок на клавиатуры заедает, печатать что-то - боль.
90 1883108
>>1877905
Так мне че-то самому интересно: регулярок как таковых же нет в sql? Там есть синтаксис для LIKE но он уебищный и во много уступает регуляркам. Как тот же номер телефона там найти?
91 1883144
>>1883108
Есть как минимум в оракле, что-то своё должно быть в других СУБД. Это нестандартная для SQL фича.
92 1883148
>>1883108

>Как тот же номер телефона там найти


sqlalchemy:

phone_pattern = '%{}%{}{}{}%{}{}{}%{}{}%{}{}'.format(*[i for i in phone])
query = sa.select([phone_table]).where(phone_table.c.phone.like(phone_pattern))

))))))
image.png16 Кб, 237x452
93 1883699
Сап аноны. Делаю бд для онлайн магазина. Каталог с возможностью добавления подкатегорий (за это отвечают столбцы parent_id и is_parent в caregories). Какие ошибки, что можно исправить? Буду благодарен за любую критику.
P. S. бд пилю впервые
94 1883702
>>1883699
картинки к продуктам храню в файловой системе, для каждого продукта есть папка с id в качестве названия. Не нашел пока другого способа, что подскажете по этому поводу?
95 1883719
>>1883699
Норм.
>>1883702
Лучше в файловой системе, скорее всего, будет работать быстрее, чем если хранить блобы в БД. Раздавать каким-нибудь нгинксом.
96 1883791
>>1883719

>Раздавать каким-нибудь нгинксом.


типа для картинок отдельно сервак поднять?
97 1883800
>>1883791
Да, но вообще от нагрузки зависит, для 3.5 анонов хватит и основного приложения.
98 1883802
>>1883800
понял, спасибо
99 1884312
>>1869798
Бамп
100 1885240
>>1869616 (OP)
Анон, какие РАСШИРЕНИЯ, делают язык SQL - тьюринг-полным?
Кроме PL/SQL и PSM, разумеется: http://assets.en.oreilly.com/1/event/27/High Performance SQL with PostgreSQL Presentation.pdf
Вижу здесь - СTE:
https://coderoad.ru/900055/Является-ли-SQL-или-даже-TSQL-Тьюринг-полным#7580013

А какие ещё вы знаете?
101 1885369
>>1869616 (OP)
Сап, аноны. Заранее прошу простить, если не по теме пишу, просто хз, куда ещё писать. Нужен человек, которых разбирается в PL\SQL

типа, есть задание, которое идёт вместо экзамена, а у меня нихуя не компилируется, ошибки в коде, а сам исправить не могу, ибо тупой

Это всё не бесплатно, конечно. Если есть тут умельцы-молодцы, то в ответе на пост пишите контакт в телеге
изображение.png628 Кб, 640x480
102 1885550
>>1885369
надо тебе ,а телегу оставлять должны мы, какой хитрый
103 1885555
>>1885550
аноны, подкиньте, пожалуйста, годный курс по power bi
чтоб быстро и эффективно въехать в тему
104 1885594
>>1885550
@black_n_black
105 1885664
>>1877902
Если нет регулярок:
TRANSLATE(phone, TRANSLATE(phone, '0123456789', ''), '');
Удаляешь всё что не является цифрой. Дальше можно первую 8 заменить на 7 и сделать из этого функциональный индекс или триггер-нормализатор телефонов при вставке в таблицу.
106 1885700
>>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);

Но вообще лучше сделать нормализацию на бэкенде (и для каждой страны свою)
107 1886036
>>1869616 (OP)
Подкиньте годноту для вката в проектирование баз данных.
В частности, где досконально поясняется за модели данных,
и за способы преобразования иерархической и сетевой модели данных в реляционные, и возможно - между собой.
Как правильно спроектировать реляционную базу данных и как её нормализовать, и вот это вот всё.
108 1886065
У меня есть своя бд из трёх таблиц. В одной из таблиц хранятся email, который должен быть уникальным. Как написать в sql(sqlite) код так, чтобы при ошибке записи(email не уникален) он удалил только что внесённые данные в другие таблицы и вышел? Я так понял надо использовать savepoint и rollback, но у меня нихуя не работает
109 1886083
>>1886065

> при ошибке записи(email не уникален) он удалил только что внесённые данные в другие таблицы и вышел


Транзакции называется. Начинаешь транзакцию через BEGIN или SAVEPOINT, выполняешь запросы, если один из запросов свалился с ошибкой, делаешь ROLLBACK, если дошли до конца без ошибок, делаешь COMMIT.
Но это если ты вручную работаешь в консольке sqlite. Если ты делаешь это из какого-то приложения, у тебя там скорее всего будет механизм управления транзакциями, где ты в начале подключаешься к БД, запускаешь транзакцию вызовом нужной функции, делаешь запросы, в конце коммитишь или откатываешь. Важно, что там скорее всего будет включён auto-commit, его надо будет выключить.
110 1886090
>>1886036
Оппик читал?
111 1886124
>>1886090
Не, он же на непонятном. Только что погуглил переводы на русский, ссылка неактивна.

У меня тут парочка вопросов назрела.
Возможно ли расширить таблицу, не добавляя поля к изначальной таблице, а создавая новую?
Возможно ли создать таблицу с кучей полей, из кучи таблиц, где есть только ID и одно поле?
То есть, имеет ли смысл, на каждое поле по таблице сделать, а потом увязать 1 к 1?
112 1886196
>>1886124
Не совсем понятно, о чём речь.

> Возможно ли расширить таблицу, не добавляя поля к изначальной таблице, а создавая новую?


Одним запросом это не сделать. Нужно явно создать новую таблицу так же, как создавалась старая таблица, затем скопировать в неё нужные данные из старой с помощью такого запроса: https://www.w3schools.com/sql/sql_insert_into_select.asp

> Возможно ли создать таблицу с кучей полей, из кучи таблиц, где есть только ID и одно поле?


Возможно, но с 1 к 1 обычно так не делают и хранят всё в одной таблице. Разве что для логического разделения сущностей, но это смотря как моделировать предметную область.
113 1886314
Поясните, чё такое функции в SQL PL?

Триггеры ебучие, эксепшены, лупы-залупы прям в моём SQL.

Скажите, в чём вообще профит использовать их и в каких проектах оно нужно? Я это только в универе сдавал, а потом пошёл работать на web backend. Для каких вообще юзкейсов надо знать PL? Или это только для тех у кого Postgres не oracle?
114 1886323
>>1886314

> Поясните, чё такое функции в SQL PL?



В смысле не чё такое, а где применяются
115 1886330
>>1886314
У нас хранимые функции/процедуры часто юзаются в скриптах миграции, где простым DML заебёшься писать кучу типовых инсертов/апдейтов. Ещё есть OLAP-база, где в таких процедурах уже логика.

> для тех у кого Postgres не oracle


Да.
116 1887058
>>1869616 (OP)
Связываются ли таблицы непосредственно внутри базы данных,
или они связываются уже на уровне логики работы с базой - через запросы какие-то вроде JOIN-хуеин?
Может ли быть внутри одной базы данных блок взаимосвязанных таблиц, которые не связаны с другими таблицами?
Может ли быть несколько баз данных в одной базе данных?
Можно ли сконвертировать всю файловую систему в базу данных?
117 1887062
>>1887058
И ещё вопрос, в догонку.
Имеет ли смысл использовать вместо базы данных, кучу папок с названием таблиц, и кучу файлов в них, со значениями строк таблиц в JSON?
Будет ли такая шняга работать шустрее, чем запросы к БД?
Будет ли это проще, нежели пердолинг с сиквелом и CУБД?
118 1887079
>>1887058

> Связываются ли таблицы непосредственно внутри базы данных,


> или они связываются уже на уровне логики работы с базой - через запросы какие-то вроде JOIN-хуеин?


Да, связываются в виде констреинтов. Ты можешь создать его явно, либо он создастся неявно при указании foreign key, когда создаёшь таблицу. Но технически это не обязательно, констреинты нужны только для проверок, что такой ключ есть в таблице, на которую ссылаются (ссылочная целостность), а так их можно вообще не создавать и делать всё на уровне логики.

> Может ли быть внутри одной базы данных блок взаимосвязанных таблиц, которые не связаны с другими таблицами?


Да, хоть вообще никак таблицы не связывай, никаких ограничений на это нет.

> Может ли быть несколько баз данных в одной базе данных?


Нет. Зато есть понятие схем, их может быть в одной БД несколько. Правда, некоторые СУБД, например, mysql, эти понятия отождествляют.

> Можно ли сконвертировать всю файловую систему в базу данных?


Зачем? Теоретически можно представить файловую систему в виде реляционной модели и написать скрипт для наполнения такой БД.
>>1887062
Только если у тебя там хранятся совсем простые данные, вроде настроек или чего-то ещё, чего немного и не жалко потерять. Для большего нельзя. Работать, скорее всего, для большинства задач будет медленнее. У тебя не будет ни транзакций, ни ссылочной целостности, ни индексов, ни оптимизации. Будет, конечно, проще, но это единственный плюс.
119 1887288
>>1887079

>Да, связываются в виде констреинтов. Ты можешь создать его явно, либо он создастся неявно при указании foreign key, когда создаёшь таблицу.


>Но технически это не обязательно, констреинты нужны только для проверок, что такой ключ есть в таблице,


>на которую ссылаются (ссылочная целостность), а так их можно вообще не создавать и делать всё на уровне логики.


Ну, эта связь физически есть внутри базы,
в том плане что задан ли где-то, в базе данных - тип связи (1 к 1, 1 ко многим, многие к 1, многие ко многим),
или же эта связь задаётся на уровне запроса, а в базе данных - просто таблицы,
и ID в качестве поля - в одной таблице, и ключевого поля с ID - в другой таблице?

>Да, хоть вообще никак таблицы не связывай, никаких ограничений на это нет.


>Нет. Зато есть понятие схем, их может быть в одной БД несколько. Правда, некоторые СУБД, например, mysql, эти понятия отождествляют.


Вот это хотел узнать. Ведь блок взаимосвязанных таблиц - это и есть база данных для какого-нибудь проекта (модель данных проекта).
И в файле .db могут быть модели данных разных проектовы - что впрочем и понимается как разные "базы данных" для разных проектов
(а не сам файл базы, ведь она может быть вообще в облаке, и может содержать множество никак не связаных друг с другом моделей данных).

> Можно ли сконвертировать всю файловую систему в базу данных?


>Зачем? Теоретически можно представить файловую систему в виде реляционной модели и написать скрипт для наполнения такой БД.


Я где-то слышал, что файловая система - это и есть база данных. Но это не точно.
Походу да, и это иерархическая БД! В том плане, что дерево папок иерархично, ну там корневой каталог, и так далее - вложенные папки...
Жесткие ссылки (hardlinks), а также ярлыки на файлы - позволяют из иерархической базы данных - сделать сетевую.
То есть один файл, будучи размещён физически на одном на определённых секторах диска, может находится в разных папках, без дублирования данных,
имея как-бы несколько взаимосвязей с этими папками.
Но, и иерархическую, и сетевую модель данных, насколько я понимаю - можно свести к реляционной модели данных (правда не понимаю как?).

Так вот, если это возможно, и если базы данных пижже
(ну там целостность, поиск, отсутствие дублирования, репликация, индексация, транзакции хуй знает чего, оптимизации),
то почему бы не хранить данные - в реляционной базе данных, вместо файловой системы,
с возможностью её подмонтировать как диск, и читать файлы из базы - BLOB'ами.
И вместо бекапов - почему бы не делать репликацию базы данных с master на slave, для пущей отказоустойчивости?
И если так, то почему бы не заебенить глобальную базу данных, где все файлы и их фрагменты, хранились бы в одном пиздатом облаке,
имели бы кучу хэшей, и если они меняются - сохранялась бы отдельно, последовательность только лишь изменений их, без дублирования?

>>1887062

>>Имеет ли смысл использовать вместо базы данных, кучу папок с названием таблиц, и кучу файлов в них, со значениями строк таблиц в JSON?


>Только если у тебя там хранятся совсем простые данные, вроде настроек или чего-то ещё, чего немного и не жалко потерять.


>Для большего нельзя. Работать, скорее всего, для большинства задач будет медленнее.


>У тебя не будет ни транзакций, ни ссылочной целостности, ни индексов, ни оптимизации. Будет, конечно, проще, но это единственный плюс.


Аа, ну да. Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной,
но это не значит что реляционную можно свести к иерархической (быть может к сетевой можно, но опять же - не знаю как).
Если значение поля в строчке таблицы базы данных - будет содержать BLOB в 500 мегабайт, то и JSON-файл со строчкой такой таблицы, будет весить 500 метров,
и чтобы проверить по условию значение другого поля в этой строчке, придётся грузить 500 метров...
Если условие не выполнено - другой файл грузится, ещё 500 метров, короче пиздец, и пижже БД.
119 1887288
>>1887079

>Да, связываются в виде констреинтов. Ты можешь создать его явно, либо он создастся неявно при указании foreign key, когда создаёшь таблицу.


>Но технически это не обязательно, констреинты нужны только для проверок, что такой ключ есть в таблице,


>на которую ссылаются (ссылочная целостность), а так их можно вообще не создавать и делать всё на уровне логики.


Ну, эта связь физически есть внутри базы,
в том плане что задан ли где-то, в базе данных - тип связи (1 к 1, 1 ко многим, многие к 1, многие ко многим),
или же эта связь задаётся на уровне запроса, а в базе данных - просто таблицы,
и ID в качестве поля - в одной таблице, и ключевого поля с ID - в другой таблице?

>Да, хоть вообще никак таблицы не связывай, никаких ограничений на это нет.


>Нет. Зато есть понятие схем, их может быть в одной БД несколько. Правда, некоторые СУБД, например, mysql, эти понятия отождествляют.


Вот это хотел узнать. Ведь блок взаимосвязанных таблиц - это и есть база данных для какого-нибудь проекта (модель данных проекта).
И в файле .db могут быть модели данных разных проектовы - что впрочем и понимается как разные "базы данных" для разных проектов
(а не сам файл базы, ведь она может быть вообще в облаке, и может содержать множество никак не связаных друг с другом моделей данных).

> Можно ли сконвертировать всю файловую систему в базу данных?


>Зачем? Теоретически можно представить файловую систему в виде реляционной модели и написать скрипт для наполнения такой БД.


Я где-то слышал, что файловая система - это и есть база данных. Но это не точно.
Походу да, и это иерархическая БД! В том плане, что дерево папок иерархично, ну там корневой каталог, и так далее - вложенные папки...
Жесткие ссылки (hardlinks), а также ярлыки на файлы - позволяют из иерархической базы данных - сделать сетевую.
То есть один файл, будучи размещён физически на одном на определённых секторах диска, может находится в разных папках, без дублирования данных,
имея как-бы несколько взаимосвязей с этими папками.
Но, и иерархическую, и сетевую модель данных, насколько я понимаю - можно свести к реляционной модели данных (правда не понимаю как?).

Так вот, если это возможно, и если базы данных пижже
(ну там целостность, поиск, отсутствие дублирования, репликация, индексация, транзакции хуй знает чего, оптимизации),
то почему бы не хранить данные - в реляционной базе данных, вместо файловой системы,
с возможностью её подмонтировать как диск, и читать файлы из базы - BLOB'ами.
И вместо бекапов - почему бы не делать репликацию базы данных с master на slave, для пущей отказоустойчивости?
И если так, то почему бы не заебенить глобальную базу данных, где все файлы и их фрагменты, хранились бы в одном пиздатом облаке,
имели бы кучу хэшей, и если они меняются - сохранялась бы отдельно, последовательность только лишь изменений их, без дублирования?

>>1887062

>>Имеет ли смысл использовать вместо базы данных, кучу папок с названием таблиц, и кучу файлов в них, со значениями строк таблиц в JSON?


>Только если у тебя там хранятся совсем простые данные, вроде настроек или чего-то ещё, чего немного и не жалко потерять.


>Для большего нельзя. Работать, скорее всего, для большинства задач будет медленнее.


>У тебя не будет ни транзакций, ни ссылочной целостности, ни индексов, ни оптимизации. Будет, конечно, проще, но это единственный плюс.


Аа, ну да. Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной,
но это не значит что реляционную можно свести к иерархической (быть может к сетевой можно, но опять же - не знаю как).
Если значение поля в строчке таблицы базы данных - будет содержать BLOB в 500 мегабайт, то и JSON-файл со строчкой такой таблицы, будет весить 500 метров,
и чтобы проверить по условию значение другого поля в этой строчке, придётся грузить 500 метров...
Если условие не выполнено - другой файл грузится, ещё 500 метров, короче пиздец, и пижже БД.
120 1887300
>>1887288

>Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной,


>но это не значит что реляционную можно свести к иерархической (быть может к сетевой можно, но опять же - не знаю как).


Если реляционную модель можно свести к сетевой, то и к иерархической, походу - но придётся дублировать эти ебучие данные.
121 1887305
Помогите плз задачку решить с 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)
Но вот как сделать их чередование я хз. Так что либо помогите допилить мое решение, либо тупо скиньте свое, в любом случае поклон вам в ноги
121 1887305
Помогите плз задачку решить с 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)
Но вот как сделать их чередование я хз. Так что либо помогите допилить мое решение, либо тупо скиньте свое, в любом случае поклон вам в ноги
122 1887316
>>1887288

> в том плане что задан ли где-то, в базе данных - тип связи (1 к 1, 1 ко многим, многие к 1, многие ко многим)


Нет, это на уровне логики/запроса.

> Ведь блок взаимосвязанных таблиц - это и есть база данных для какого-нибудь проекта


База данных - это более конкретная вещь, а не просто абстрактное понятие для набора таблиц. Это именно общее хранилище для разных сущностей, взаимосвязанных или нет. "Модели" может и разные, но база в любом случае одна. Например, "удалить базу данных" значит удалить все эти модели одновременно, которые якобы не связаны. Но это с практической точки зрения, принятой в терминологии SQL. Терминология может отличаться в других подходах.

> Я где-то слышал, что файловая система - это и есть база данных. Но это не точно.


Можно и единственный текстовый файл со списком чего-либо назвать базой данных, и в каком-то смысле это будет правильно.

> Но, и иерархическую, и сетевую модель данных, насколько я понимаю - можно свести к реляционной модели данных (правда не понимаю как?).


Например, есть такая таблица: id | parent_id | is_file | name
id - просто айдишник, parent_id - ссылка на запись в этой же таблице, is_file - признак файла/каталога, name - название. И так можно строить иерархии. С сетевой моделью уже будет отдельная таблица связей многие-ко-многим. А содержимое файлов хранить в отдельной таблице, которая будет ссылаться на первую таблицу.

> почему бы не хранить данные - в реляционной базе данных, вместо файловой системы


Иногда БД - это лишний оверхед. В БД на первое место ставится надёжность, чтобы во что бы то ни стало не проебать данные, и пусть запрос ради этого хоть 100 лет выполняется. А если ты хочешь просто скачать пак с котиками, то тебе может быть всё равно, что процесс копирования остановится раз в много лет на 90%, проще скопировать заново либо вообще забить.

> И если так, то почему бы не заебенить глобальную базу данных, где все файлы и их фрагменты, хранились бы в одном пиздатом облаке,


Хотя бы из-за медленной скорости интернета по сравнению с жёстким диском. Есть шутка про то, что быстрее всего данные передаёт грузовик с жёсткими дисками.

> Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной, но это не значит что реляционную можно свести к иерархической


Да всё ко всему можно в предельном случае, лишь бы была программа, которая может это прочитать и представить в нужном виде.
122 1887316
>>1887288

> в том плане что задан ли где-то, в базе данных - тип связи (1 к 1, 1 ко многим, многие к 1, многие ко многим)


Нет, это на уровне логики/запроса.

> Ведь блок взаимосвязанных таблиц - это и есть база данных для какого-нибудь проекта


База данных - это более конкретная вещь, а не просто абстрактное понятие для набора таблиц. Это именно общее хранилище для разных сущностей, взаимосвязанных или нет. "Модели" может и разные, но база в любом случае одна. Например, "удалить базу данных" значит удалить все эти модели одновременно, которые якобы не связаны. Но это с практической точки зрения, принятой в терминологии SQL. Терминология может отличаться в других подходах.

> Я где-то слышал, что файловая система - это и есть база данных. Но это не точно.


Можно и единственный текстовый файл со списком чего-либо назвать базой данных, и в каком-то смысле это будет правильно.

> Но, и иерархическую, и сетевую модель данных, насколько я понимаю - можно свести к реляционной модели данных (правда не понимаю как?).


Например, есть такая таблица: id | parent_id | is_file | name
id - просто айдишник, parent_id - ссылка на запись в этой же таблице, is_file - признак файла/каталога, name - название. И так можно строить иерархии. С сетевой моделью уже будет отдельная таблица связей многие-ко-многим. А содержимое файлов хранить в отдельной таблице, которая будет ссылаться на первую таблицу.

> почему бы не хранить данные - в реляционной базе данных, вместо файловой системы


Иногда БД - это лишний оверхед. В БД на первое место ставится надёжность, чтобы во что бы то ни стало не проебать данные, и пусть запрос ради этого хоть 100 лет выполняется. А если ты хочешь просто скачать пак с котиками, то тебе может быть всё равно, что процесс копирования остановится раз в много лет на 90%, проще скопировать заново либо вообще забить.

> И если так, то почему бы не заебенить глобальную базу данных, где все файлы и их фрагменты, хранились бы в одном пиздатом облаке,


Хотя бы из-за медленной скорости интернета по сравнению с жёстким диском. Есть шутка про то, что быстрее всего данные передаёт грузовик с жёсткими дисками.

> Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной, но это не значит что реляционную можно свести к иерархической


Да всё ко всему можно в предельном случае, лишь бы была программа, которая может это прочитать и представить в нужном виде.
123 1887322
>>1869616 (OP)
Почему про встраиваемую SQLite в ОП-шапке ни слова? Опенсорц же? Или просто - ОП-хуй?
# OP 124 1887334
>>1887322

> SQLite


Надо добавить, но там много не накопать в отрыве от ЯПов.

> Опенсорц же?


Зато у меня там много проприетарщины.

> ОП-хуй?


Безусловно.
125 1887350
>>1887316

>Нет, это на уровне логики/запроса.


Ок. Принято. Значит реляционная модель - это просто определённым образом организованные таблицы, и не более. А то мне постоянно мерещатся какие-то физические взаимосвязи между ними, в виде указателей.
Вчера как-то жёппой читал это, прост: https://www.internet-technologies.ru/articles/modeli-baz-dannyh-sistemy-upravleniya-bazami-dannyh.html#header-10697-5

>Например, есть такая таблица: id | parent_id | is_file | name


>id - просто айдишник, parent_id - ссылка на запись в этой же таблице,


>is_file - признак файла/каталога, name - название.


>И так можно строить иерархии.


>С сетевой моделью уже будет отдельная таблица связей многие-ко-многим.


>А содержимое файлов хранить в отдельной таблице, которая будет ссылаться на первую таблицу.


Коротко и ясно.

>> почему бы не хранить данные - в реляционной базе данных, вместо файловой системы


>Иногда БД - это лишний оверхед. В БД на первое место ставится надёжность,


>чтобы во что бы то ни стало не проебать данные, и пусть запрос ради этого хоть 100 лет выполняется.


>А если ты хочешь просто скачать пак с котиками, то тебе может быть всё равно,


>что процесс копирования остановится раз в много лет на 90%, проще скопировать заново либо вообще забить.



>> И если так, то почему бы не заебенить глобальную базу данных,


>>где все файлы и их фрагменты, хранились бы в одном пиздатом облаке,


>Хотя бы из-за медленной скорости интернета по сравнению с жёстким диском.


>Есть шутка про то, что быстрее всего данные передаёт грузовик с жёсткими дисками.



У меня чё-то засела идея, один файл .db на весь раздел захуярить, с базой SQLite,
и туда, короче - данные писать, и монтировать его как диск, как файловую систему.
Но минусы, конечно же есть. Это bad-секторы.
Значит надо два файла, походу, и репликацию заебенить. И ремап. Тупая, короче, идея.

>> Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной,


>>но это не значит что реляционную можно свести к иерархической


>Да всё ко всему можно в предельном случае, лишь бы была программа, которая может это прочитать и представить в нужном виде.


Что ещё не заебенили? Мне что-ли нарукожопить эту хуйню?
125 1887350
>>1887316

>Нет, это на уровне логики/запроса.


Ок. Принято. Значит реляционная модель - это просто определённым образом организованные таблицы, и не более. А то мне постоянно мерещатся какие-то физические взаимосвязи между ними, в виде указателей.
Вчера как-то жёппой читал это, прост: https://www.internet-technologies.ru/articles/modeli-baz-dannyh-sistemy-upravleniya-bazami-dannyh.html#header-10697-5

>Например, есть такая таблица: id | parent_id | is_file | name


>id - просто айдишник, parent_id - ссылка на запись в этой же таблице,


>is_file - признак файла/каталога, name - название.


>И так можно строить иерархии.


>С сетевой моделью уже будет отдельная таблица связей многие-ко-многим.


>А содержимое файлов хранить в отдельной таблице, которая будет ссылаться на первую таблицу.


Коротко и ясно.

>> почему бы не хранить данные - в реляционной базе данных, вместо файловой системы


>Иногда БД - это лишний оверхед. В БД на первое место ставится надёжность,


>чтобы во что бы то ни стало не проебать данные, и пусть запрос ради этого хоть 100 лет выполняется.


>А если ты хочешь просто скачать пак с котиками, то тебе может быть всё равно,


>что процесс копирования остановится раз в много лет на 90%, проще скопировать заново либо вообще забить.



>> И если так, то почему бы не заебенить глобальную базу данных,


>>где все файлы и их фрагменты, хранились бы в одном пиздатом облаке,


>Хотя бы из-за медленной скорости интернета по сравнению с жёстким диском.


>Есть шутка про то, что быстрее всего данные передаёт грузовик с жёсткими дисками.



У меня чё-то засела идея, один файл .db на весь раздел захуярить, с базой SQLite,
и туда, короче - данные писать, и монтировать его как диск, как файловую систему.
Но минусы, конечно же есть. Это bad-секторы.
Значит надо два файла, походу, и репликацию заебенить. И ремап. Тупая, короче, идея.

>> Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной,


>>но это не значит что реляционную можно свести к иерархической


>Да всё ко всему можно в предельном случае, лишь бы была программа, которая может это прочитать и представить в нужном виде.


Что ещё не заебенили? Мне что-ли нарукожопить эту хуйню?
126 1887354
Как в sqlite сделать поиск русских слов по таблице регистронещависмо?
127 1887361
>>1887354
Глянь тут: https://stackoverflow.com/questions/22343850/sqlite-like-case-insensitive-for-not-english-letters
или в гугле, по запросу "sqlite search case insensitive cyrillic"
128 1887364
>>1887350

> репликацию


Оба файла могут попасть на bad-сектора, и если какой-нибудь заголовок похерится, куча данных проебётся. Не стал бы я хранить огромные бинарные файлы на дешёвом диске.

> Что ещё не заебенили? Мне что-ли нарукожопить эту хуйню?


Обычно нет смысла, делать из буханки автобус, вместо этого берут другой тип БД.
129 1887365
>>1887354
lower()
130 1887366
>>1887354
Во: https://stackoverflow.com/a/973785

>SELECT * FROM ... WHERE name = 'someone' COLLATE NOCASE


>COLLATE NOCASE


+ LIKE UPPER('%pattern%');
131 1887367
>>1887365
А, ну да, только с латиницей раотает.
132 1887448
>>1887305
Чото ты херню каку-то делаешь. Через оконные функции попробуй. Делаешь row number(простой и desc) для каждой таблицы до обьеденения, потом по нему сортируешь, если нужен особый порядок сортировки, меняешь нумерацию на основе обоих столбов через CASE.

Твоё решение говно потому-что обьеденений будет явно больше трёх, ты чё для каждого будешь селект с юнионом корячить? Так что склеиваешь всё сразу, а потом уже дрочишся с сортировкой.
133 1887540
Работал с гринпламом кто? Или тут одни пузаны из банков?
134 1887558
>>1886314

> Скажите, в чём вообще профит использовать их и в каких проектах оно нужно


никакого профита нет, только легаси и административная хуйня типа миграции данных и распределения данных при партиционировании. за использование скриптов субд в бизнес-логике руки отрывают лет 20 уже как.

это остатки хайповой технологии 50-летней давности, когда была идея фикс писать приложения прямо в БД. сейчас код на плскл это то же самое что код на коболе.
135 1887563
>>1887062

>Имеет ли смысл использовать вместо базы данных, кучу папок с названием таблиц, и кучу файлов в них, со значениями строк таблиц в JSON?


не имеет

> Будет ли такая шняга работать шустрее, чем запросы к БД?


будет работать медленнее на порядок, а может и на три

> Будет ли это проще, нежели пердолинг с сиквелом и CУБД?


будет сложнее на два порядка
136 1887572
>>1886314
Представь, что тебе нужно рассчитать много данных, примерно, 1 тер. Плюс должен быть пользователь который задаёт алгоритм расчёта руками через интерфейс. Как сделать это без хранимок?
137 1887574
>>1887572

> Как сделать это без хранимок?


на любом нормальном ЯП, например, не?
138 1887575
>>1887574
Ты питоном собрался 1 терабайт данных обрабатывать? А субд какую юзать будешь?
139 1887577
>>1887572
Вот и получается, что юз-кейс хранимок - это только аналитика.
>>1887574
Грузить терабайт в ОЗУ, считать и сохранять обратно, так?
140 1887579
>>1887577

>Грузить терабайт в ОЗУ


Медленно и зачем?
141 1887584
>>1887575

> Ты питоном собрался 1 терабайт данных обрабатывать?


ну если он поддерживает стрим данных/курсоры то можно и питоном.

> А субд какую юзать будешь?


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

>>1887577

>Грузить терабайт в ОЗУ, считать и сохранять обратно, так?


ты задачу то опиши, что за обработка такая где нужно терабайт в память грузить и как с этим может справится субд?
142 1887587
>>1887584

> такая где нужно терабайт в память грузить


Например, тебе нужно посчитать зп которая от продаж продаванов крупного ритейла. Можешь считать, что пользователь самостоятельно задаёт алгоритм расчёта. Для этого пользователю необходим интерфейс, поэтому это далеко не BI отчёт.

>постгрес, оракл, мсскл


Любой из, зависит от источника данных

>как с этим может справится субд


Вполне легко?
143 1887598
НА ВОПРОСЫ НИКТО НЕ ОТВЕЧАЕТ
@
SQL НИКТО НЕ ОБСУЖДАЕТ
@
ДА И ВОБЩЕ НАМ ВАШ SQL НАХУЙ НЕНУЖОН
144 1887605
>>1887598
SQL совершенен, вот и обсуждать нечего.
145 1887801
>>1869616 (OP)
>>1886036
>>1887288
>>1887300
>>1887316

Если иерархическую и сетевую модель данных можно сконвертировать в реляционную, и наоборот,
то можно ли нейросетевую модель данных представить в виде реляционной модели?!!
Будет ли она фурычить также как фурычат мозги?
146 1887841
>>1887587

> Например, тебе нужно посчитать зп которая от продаж продаванов крупного ритейла.


и зачем тебе для этого хранимка? это стандартнейший кейс для сервис-лэйера приложений, нафига его в уровень бд пихать?
147 1887844
>>1887587

> Вполне легко?


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

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

и нет ни одной разумной причины чтобы какую-либо бизнес-логику писать в хранимках. при этом логику в приложении ты можешь написать на нормальном языке, она легко изменяется, параметризуется и т.д. а в хранимках с этим большой пиздец.
149 1887863
Нужно ли для сис админа знать sql?
150 1887896
>>1887849

> MVP


> В мире стартапов и начинающего бизнеса денег нет. Есть только немного человеческого ресурса. Спека? Пффф... Это непозволительная роскошь. Тестеры? Пфф... Девопсы? Ну вы поняли.


> Я храню все данные в файловой системе, как простой json файл. Это очень быстро, просто, и это отлично работает.


> RAMа так много, что диск нужен лишь меньшинству



И это пишет джавист? Раз ему нужно срочно клепать дохуя неподдерживаемого говна, выбор жабы вызывает много вопросов. А почему тогда не пыха и js?
151 1887912
>>1887863
Смотря какому, кому-то нужно.
152 1887932
>>1887896
А хуй знает, спроси его. Но как я понял из статьи, БД и СУБД не нужны, потому что дохуя ебалы, и можно сделать всё проще, на низком уровне.
153 1887933
>>1869616 (OP)
Аноны, подскажите, как лучше быть в такой ситуации.
Я тут делаю бэк к одному приложению. Оно подключено к бд, которая будет меняться откуда-то ещё, т.е. не только изнутри приложения.
И, значит, есть форма, где на фронте пользователь будет создавать новые объекты в одной мега-большой таблице. В этой таблице около 70 полей, из низ 30 ограничены вариантами из валидационных таблиц. Допустим, в одном поле выбирается из списка допустимых стран, в другом - какой-нибудь там тип кредита или опциона или ещё чего. Все эти типы могут со временем меняться, так что не захардкодить, а сами данные в базе могут меняться откуда-то ещё, извне моего приложения, так что и закэшировать нормально не выйдет.
И вот я не хочу делать 30 селектов к базе, чтобы получить допустимые значения по этим валидационным таблицам. Как мне быть, какой лучше составить запрос? Или тут лучшим вариантом будет сделать какую-то вьюху на стороне базы, которая бы объединяла эти данные и обновляла автоматически, а я дергал уже её? Хотелось бы без этого обойтись
154 1888013
>>1887896
да это переводная статья десятилетней давности. написанная на хайпе всяких монгодб и прочих мусоросборников. доводы что там описаны обоссаны по сто раз уже.
155 1888018
>>1887912
Пример можно?
156 1888029
>>1887932

> Но как я понял из статьи, БД и СУБД не нужны, потому что дохуя ебалы, и можно сделать всё проще, на низком уровне.


нет. смысл статьи - если ваше говно умрет через 1 год то зачем заморачиваться?

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

> Я храню все данные в файловой системе, как простой json файл. Это очень быстро, просто, и это отлично работает.


> 100К активных пользователей — ровно столько я могу обслуживать с 1 ГБ RAM на виртуалке за 10 у.е.


ололо блядь. и такой пиздеж всю дорогу

любая самая простая субд типа h2 просто порвет его json файлы в оперативке по производительности в клочья, когда потребуется сделать что-нибудь посерьезнее выборки пользователей по ключу. потому что тупо свалить все говно в оперативку - это не значит сделать выборку данных быстрее. чтобы оно быстро выбиралась нужно строить индексы, деревья и использовать продвинутые алгоритмы поиска. а если тупо массив в памяти держать и перебором его обходить каждый раз когда потребуются данные - это будет просто пиздец как медленно.
157 1888033
>>1888013
Ладно ещё монга, он же вообще предлагает всё хранить тупо в файлах и ОЗУ. Как деды в середине прошлого века.
158 1888036
>>1887933

> И вот я не хочу делать 30 селектов к базе


почему, в чем проблема сделать 30 селектов?
160 1888049
>>1888036
30 селектов - это 30 реквестов к удаленной базе. Это долго.
161 1888051
>>1888049
долго - это сколько в миллисекундах?
162 1888058
>>1888051
Ну вот с моего локального компа выходит по 0.068 секунд на один такой запрос. На проде всё будет быстрее, я думаю, раз в 10-20, так как всё в одном клауде находится. Но всё равно, это 30 запросов, мне кажется, что можно сделать как-то по-другому, как-то лучше.
163 1888073
>>1888058

> Но всё равно, это 30 запросов, мне кажется, что можно сделать как-то по-другому, как-то лучше.



ты можешь запросы юнионом объединять, но это тебе практически не прибавит скорости если база и сервак соеденены через локальную сеть, а геморроя в разработке добавит. это решение, в принципе, аналогично вьюхе которую ты хочешь создать.

еще решения:

1) настрой себе кеш и сбрасывай его раз в минуту например, судя по тому что ты описал это вполне приемлемо.

2) настрой триггеры на изменение какой-нибудь переменной в БД при обновлении данных. перед своими запросами проверяй ее и сбрасывай свой кеш тогда когда эта переменная изменилась.

3) сделай единую точку входа для получения и обновления данных и помести туда кеш.
164 1888126
>>1888073
Благодарю
165 1888223
>>1887844
Т. е. ты считаешь, что лучше писать курсоры, которые запускают SQL? Ты уверен, что это будет красивей?
166 1888259
>>1888223

> Т. е. ты считаешь, что лучше писать курсоры, которые запускают SQL? Ты уверен, что это будет красивей?


найти задачу в которой тебе действительно потребуются курсоры - это еще надо постараться.

код который занимается обработкой данных должен быть в одном месте, и это аксимома разработки. если у тебя бизнеслогика размазана между сервером приложений и субд - это жопа. зачем тебе хранимка, если ты можешь весь код из нее просто взять и запустить в виде SQL-запроса?
167 1888273
>>1888259
Так если мы засовываем логику в запросы, то зачем нам вызвать запросы на сервере приложений? Процедурный sql в данном плане гораздо удобнее.
1608731152866.png10 Кб, 603x354
168 1888290
Аноны, помогите, плиз, решить задачу, второй день не могу справиться. Хотя бы идею подкиньте. :'с

Задание:
Вывести логины пользователей, у которых куплены ТОЛЬКО игры, выпущенные американцами в чётном году.

Мой вариант:
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

Коммент препода:
Не ОК. У тебя, получается, выбираются все пользователи, у которых хотя бы одна игра попадает под условие. А нам надо, чтобы выводились только те пользователи, у которых ВСЕ игры на аккаунте сделаны в Америке и выпущены в четном году. Т.е., если у пользователя есть хотя бы одна игра, не подходящая под условие-он нам не подходит. Попробуй идти от обратного Ты ищешь игры, а не пользователей. Посмотри в сторону подзапроса.

ЧЯДНТ?
image.png433 Кб, 1150x864
169 1888295
>>1869616 (OP)
>>1887316

>С сетевой моделью уже будет отдельная таблица связей многие-ко-многим.


Являются ли связи - отдельными таблицами?
Если да, то можно ли где-то просмотреть примеры таблиц, для связей: "1 к 1", "1 к M", "M к 1" и "M к N"?
Как понять пикрил?
Возможно ли реализовать связь "M к N" при помощи одних лишь таблиц, без этих вот связей, которые сверху соединяют таблицы?

Дело в том, что я всё-ещё смотрю на них, на эти связи, как на что-то неведомое, и реально соединяющее эти вот ебучие таблицы.
Если этими связями, являются, просто, отдельные таблицы, с индексами то базара нет.
Ведь как мы уже выяснили ITT, никаких связей в реляционной БД может не быть вовсе, там могут быть тупо таблицы.
Но я всё ещё слабо представляю себе, как именно на них реализуется эти вот связи, неведомые.
170 1888301
>>1888295

>Являются ли связи - отдельными таблицами?


Да, если это многие ко многим там появляется ещё одна таблица.

>Возможно ли реализовать связь "M к N" при помощи одних лишь таблиц, без этих вот связей, которые сверху соединяют таблицы


Да, связи между таблицами это всего-лишь ограничения на изменения данных в этих таблицах.

>как именно на них реализуется эти вот связи


Почитай про ключи и констрейнты.
171 1888304
>>1888273
>>1888259
Более того - какая разница что ты дёргаешь - запросы или процедуры. Если код запросов повторяется, зачем плодить лишний код?
172 1888319
>>1888304

> Более того - какая разница что ты дёргаешь - запросы или процедуры. Если код запросов повторяется, зачем плодить лишний код?


какой лишний код? разница тут - в поддержке и разработке.

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

во вторых - любая задача, отличающая ся от джойна трех таблиц реализорванная например на PL/SQL - это нечитаемый пиздец. это практически неподдерживаемый код, который пишет один раз а при необходимости изменений переписывается с нуля.
173 1888321
>>1888301

>Да, если это многие ко многим там появляется ещё одна таблица.


Я вот попытался, мысленно, представить связи в виде таблиц,
и воссоздать таблицы, обозначающие связь между таблицами.

Получилось вот что:

Связи, A:B (1:1, 1:M, M:1, M:N) в виде таблиц

A|...
0|...
1|...
2|...

B|...
0|...
1|...
2|...

A:B (1:1)
A|B|
0|1|
1|2|
2|5|
3|9|

A:B (1:M)
id|A|B|
0|1|2|
1|1|3|
2|1|5|
3|2|3|
4|5|7|

A:B (M:1)
id|A|B|
0|1|1|
1|2|1|
2|3|1|
3|2|3|
4|5|7|

A:B (M:N)
id|A|B|
0|1|2|
1|1|3|
2|1|5|
3|1|1|
4|2|1|
5|3|1|
6|2|3|
7|5|7|

То есть, как я понял, можно не связывать таблицы вообще, а просто создать эти вот таблицы-связи,
и по ним уже смотреть как связаны таблицы с ключами A и B?

Ты говоришь, что появляется ещё одна таблица, для связи A и B? Нафига,
если судя по всему, она содержит три поля, как и две предыдущие таблицы (1:M и M:1).

>Да, связи между таблицами это всего-лишь ограничения на изменения данных в этих таблицах.


Это вся их суть? Я думал там глубже намного, тот же поиск связанных данных, например...

>Почитай про ключи и констрейнты.


А где прочитать?
Вижу в гугле что Foreign Key - это первичный ключ, ну id для каждой таблицы, который по определению должен быть всегда уникальным.
А вот КАК ПРОИХОДИТ взаимосвязь этих Keys, при соединении таблиц в базе, - дремучий лес какой-то,
походу связываются эти таблицы - какими-то неведомыми механизмами, проприетарными,
копирастическими, и коммерчески-корпоративными, механизмами - код которых - закрыт, блядь.
Если их, эти связи можно просто реализовать таблицами, то тогда другой базар, а так - магия какая-то, за которую надо нести копирастам бабала.
173 1888321
>>1888301

>Да, если это многие ко многим там появляется ещё одна таблица.


Я вот попытался, мысленно, представить связи в виде таблиц,
и воссоздать таблицы, обозначающие связь между таблицами.

Получилось вот что:

Связи, A:B (1:1, 1:M, M:1, M:N) в виде таблиц

A|...
0|...
1|...
2|...

B|...
0|...
1|...
2|...

A:B (1:1)
A|B|
0|1|
1|2|
2|5|
3|9|

A:B (1:M)
id|A|B|
0|1|2|
1|1|3|
2|1|5|
3|2|3|
4|5|7|

A:B (M:1)
id|A|B|
0|1|1|
1|2|1|
2|3|1|
3|2|3|
4|5|7|

A:B (M:N)
id|A|B|
0|1|2|
1|1|3|
2|1|5|
3|1|1|
4|2|1|
5|3|1|
6|2|3|
7|5|7|

То есть, как я понял, можно не связывать таблицы вообще, а просто создать эти вот таблицы-связи,
и по ним уже смотреть как связаны таблицы с ключами A и B?

Ты говоришь, что появляется ещё одна таблица, для связи A и B? Нафига,
если судя по всему, она содержит три поля, как и две предыдущие таблицы (1:M и M:1).

>Да, связи между таблицами это всего-лишь ограничения на изменения данных в этих таблицах.


Это вся их суть? Я думал там глубже намного, тот же поиск связанных данных, например...

>Почитай про ключи и констрейнты.


А где прочитать?
Вижу в гугле что Foreign Key - это первичный ключ, ну id для каждой таблицы, который по определению должен быть всегда уникальным.
А вот КАК ПРОИХОДИТ взаимосвязь этих Keys, при соединении таблиц в базе, - дремучий лес какой-то,
походу связываются эти таблицы - какими-то неведомыми механизмами, проприетарными,
копирастическими, и коммерчески-корпоративными, механизмами - код которых - закрыт, блядь.
Если их, эти связи можно просто реализовать таблицами, то тогда другой базар, а так - магия какая-то, за которую надо нести копирастам бабала.
174 1888327
>>1888321

> Это вся их суть? Я думал там глубже намного, тот же поиск связанных данных, например...


да, ты правильно говоришь, тот же постгрес сразу индексы на форенкеи строит

> за которую надо нести копирастам бабала.


чет-тебя понесло не туда
175 1888340
>>1869616 (OP)
В чём профит нереляционных моделей данных и нереляционных СУБД?
176 1888342
>>1888340
профит сомнителен
177 1888362
>>1888342
Тогда такой вопрос:
Возможно ли свести к реляционной модели все эти вот модели данных: https://ru.wikipedia.org/wiki/Модель_данных#Примеры
или есть среди них какие-то несводимые, которые если не пижже реляционной модели, то какие-то особенные дохуя?
178 1888371
>>1888319

> реализующий бизнес-логику


В таком случае нам нужно отталкиваться от определения бизнес логики. Вызов SQL кода питоном/жабой/php без процедур это бизнес логика? Если нет то да, нам нужно перенести логику в хранимки/триггеры. Аргумент от

>PL/SQL - это нечитаемый пиздец


не принимается так как в твоём случае от этого поста >>1887844

>хранимка - это всего лишь набор SQL-запросов, которые ты просто можешь вызвать из приложения


мы должны будем также корректировать SQL код те же яйца только в профиль, который без динамики действительно рано или поздно станет нечитабельным говном. Да и pl/sql вполне легко читать, нужно лишь уметь это делать.
Если же вызов SQL кода это не бизнес логика, то я с твоими предпосылками не согласен.
179 1888373
>>1888371

>Если же вызов SQL кода это не бизнес логика


Это бизнес логика*
180 1888418
>>1888362
к реляционной модели можно свести практически все. более того, любую реляционную модель можно всегда свести к трем таблицам.
только нахуя тебе все эти теоретические изъебства?

основная претензия к нереляционным базам заключается в том что в них очень хуёвая обработка связности и огромное дублирование данных, и огромные проблемы с их обновлением при большом объеме хранилища. а как только начинаются попытки решить эти проблемы то получаются велосипеды которые оракл изобрел еще полвека назад.
181 1888446
>>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

посмотри код на гитхабе, это натурально недалеко от кобола ушло
https://github.com/pauldzy/DZ_JSON/blob/master/dz_json_deploy.sql
https://github.com/method5/plsql_lexer/blob/master/packages/plsql_lexer.plsql
181 1888446
>>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

посмотри код на гитхабе, это натурально недалеко от кобола ушло
https://github.com/pauldzy/DZ_JSON/blob/master/dz_json_deploy.sql
https://github.com/method5/plsql_lexer/blob/master/packages/plsql_lexer.plsql
182 1888465
>>1888446
вот пожалуйста типичный пример функций на PL/SQL для обработки текстовых данных. даже не рискну вникать что тут написано, но уверен что на перле/питоне/яве это заняло бы строчек пять
183 1888473
>>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.
Ну и минимальные, базовые знания к проектированию этих вот баз данных,
разумеется, с возможностью их расширения, этих вот знаний, законспектированных.
183 1888473
>>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.
Ну и минимальные, базовые знания к проектированию этих вот баз данных,
разумеется, с возможностью их расширения, этих вот знаний, законспектированных.
image.png462 Кб, 920x832
184 1888475
>>1888473
Пикрил отклеилась.
185 1888482
>>1888473

> Вау! Чё реально, не более трех таблиц, у реляционной модели произвольной сложности? Как на пикрил, скажем.


да. таблица объекты(аттрибуты), таблица их значений, и таблица для связи объектов между собой. к этому можно свести абсолютно любую реляционную модель.
186 1888491
Как будет выглядеть запрос в mysql, если при существующем name, в её колонку amound добавляется +1.
Если не существует name, то добавить её, а amount оставить 1.

Загуглить не могу нормально, уже раз 15 попробовал.
187 1888502
SELECT id, x, SUM(SELECT count FROM boba WHERE id = yoba.id) FROM yoba
Поясните увальню, как этот SUM использовать?
188 1888515
>>1888491
bump

Таблица такая:
id | name | amount

Все просто же, но нихуя не понятно.
189 1888531
>>1888515
select (case when name is null then amount + 1 else amount - 1 end) from ...
Как-то так, наверное
190 1888542
>>1888465
Лол, по моему это прям вообще интуитивно понятный код.
191 1888549
>>1888446

>это не ок, потому что ты не знаешь что это за calcMyGridSize и что он делает.


Ты не понял мою постановку задачи. Это не удивительно, скорее всего ты не работал в масштабных проектах и не знаешь зачем эти технологии нужны
Ты не сможешь написать обработку, потом что у тебя пк сгорит, если ты в хэшмэпе будешь обрабатывать больше 200 гигов. Нахуя тебе делать селект, если от тебя необходим расчёт?
192 1888582
>>1888549

> Ты не сможешь написать обработку, потом что у тебя пк сгорит, если ты в хэшмэпе будешь обрабатывать больше 200 гигов.


для этого есть бэтч лоадинг или курсоры или датастримы и тому подобное. но повторяю, ты покажи реально задачу, где нужно построчно пробегать по таблицам, в 99 процентах случаев это все спокойно заменяется групповыми и агрегатными запросами.

ты же сам написал

>хранимка - это всего лишь набор SQL-запросов, которые ты просто можешь вызвать из приложения


> мы должны будем также корректировать SQL код те же яйца только в профиль, который без динамики действительно рано или поздно станет нечитабельным говном


ну да, так и нужно делать. побочный эффект - адовая обработка данных, пример которых на скриншотах выше, заменяется функциями на нормальном языке.
193 1888635
>>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), тогда это вообще какая-то многомерная хуета получается, а не просто таблица.
193 1888635
>>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), тогда это вообще какая-то многомерная хуета получается, а не просто таблица.
194 1889020
Поясните. Последовательность операций не меняющих содержимое базы считается за ТРАНЗАКЦИЮ?

незаметил новый тред сразу сорян
195 1889035
>>1887572
Кажется, сейчас для этого моден хадуп.
Причем, изначальные цели сместились и для простого хранения есть clickhouse
196 1889038
>>1888033
Так ему вообще хранить не надо. Эта штука, blynk, типа прокси для ардуинщиков. Данные передаются, но не записываются
197 1889120
>>1889020
Всё считается транзакцией, даже если ты между бегином и коммитом вообще не выполнял запросов.
198 1889211
>>1887558

Чёт прям жёсткое заявление. А насколько тру? Шо, даже простейшие триггеры хуйня? С другой стороны, это же неудобно. Если у тебя есть в коде миграции, то это надо код всего триггера через plain sql на up() закидывать и на drop() скидывать. Это ебаная срака и неудобно. Может есть какие-то инструменты, но я не знаю.

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

Точно легцы уже сто лет как?

>>1887572
А как эта ебень пишется и тестится? Какой воркфлоу? Миграции?
199 1889224
>>1889035

>моден хадуп.


Для одного террабайта? Хадуп это про даталейки двх нового поколеня.
200 1889265
>>1889224

> даталейки


Не зря сижу на дваче, постоянно узнаю что-то новое.
мимо
201 1889410
>>1889120
Понял. Спасибо
202 1889506
>>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)
)
)
Ищем сначала все игры, которые НЕ подходят - выпущены либо не американцами, либо в нечётных годах. Находим все транзакции, в которых покупались такие игры. Находим все аккаунты, к которым отностятся транзакции. Берём все аккаунты и исключаем из них аккаунты из неподходящими транзакциями. Берём логины по аккаунтам.
203 1889559
>>1889506
Выглядит логично и красиво, но выдает пустой столбец логинов а логины должны быть. Но спасибо за ответ в любом случае
204 1889571
>>1889559
Попробуй позапускать отдельные подзапросы, вдруг на каком-то моменте я начинаю делать что-то не то. Тут надо сидеть и разбираться, сам сходу ошибку не смогу найти.
205 1889585
>>1889571
что-то не то судя по всему ниже этой строчки но это не точно
select account_id from transactions where account_id not in
Когда я убираю not, мне выдает список вообще всех логинов, то есть неподходящие видимо все. Но я могу ошибаться, только вкатываюсь в SQL и творю хуйню. Поковыряюсь ещё.
206 1889621
>>1889585

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'
207 1889651
>>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
207 1889651
>>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
208 1889683
>>1889651
Спасибо, завтра попробую залупу
Чем принципиально твой вариант отличается от моего? Я не доебываюсь, просто хочу понять, что именно преподу могло не понравиться в моём запросе, при том, что запрос выдавал нужные логины.
209 1889791
чем отлич классич БД от nosql?
для чего их создали?
210 1889816
>>1889791
Тем и отличаются, что сделаны не так, как реляционные, а как-то по-другому. В реляционных у тебя таблицы, взаимосвязи через ключи, нормализация, транзакции, статическая схема. В NoSQL у тебя могут быть, например, хранилища JSON или XML, ключи-значения или даже графы.
Для чего это нужно - не везде требуется такая надёжность ценой скорости, как в реляционных. Например, key-value кеш в ОЗУ. который не страшно проебать при перезапуске сервера. Или какие-нибудь JSON-ки, которые можно восстановить из бэкапа (в предположении, что делать это придётся очень редко), делаемого раз в день, а остальное вычислить заново.
211 1889968
>>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|
212 1889975
>>1889968

>соответствует этот же "id" во второй таблице, и никакой другой.


Звучит так, как будто "и никакой другой таблице".
Конечно же, имел в виду, что никакой другой "id", кроме того "id", который в первой таблице, равен "id"'у во второй таблице.

Ну, блядь, короче:
|idA12|fieldA1|fieldA2|...|
|1|a10|a20|...|
|2|a11|a21|...|
|...|a...|a...|...|

|idA34|fieldA3|fieldA4|...|
|1|a30|a40|...|
|2|a31|a41|...|
|...|a...|a...|...|

связываем две таблицы по foreign keys idA12 и idA34 связью 1 к 1,
получаем бессмысленную таблицу:
|idA12|idA34|
|1|1|
|2|2|
|...|...|

где idA12 всегда равно idA34.
Но для связи 1 к 1, эти значения могут быть и не равны, как в примере предыдущего поста.
Короче, отсюда и вопрос.
213 1890076
>>1889968
Чот ничо не понял. Зачем тебе третья таблица? Какой ещё порядок значений?
В любом случае для 1 к 1 хватит двух таблиц.
Связь 1 к 1 с двумя таблицами делается тупо хранением id первой таблицы во второй + констреинт, что во второй таблице id первой уникален, этим констреинтом можно гарантировать, что не будет больше одной записи, ссылающихся на одну и ту же запись в первой таблице (как 1 ко многим).
Таблица1:
- id
- другие столбцы
Таблица2:
- id
- таблица1_id -> таблица1.id UNIQUE
- другие столбцы

Правда, обычно 1 к 1 хранится в одной таблице.
214 1890288
>>1889683
Нужны два условия и год и игра. У тебя фильтр where применяется ко всему запросу.

Хотя у меня подозрение, что твой препод просто ебанный дед,которому нужно чтоб решили по евонному, через подзапрос. Но как известно любую задачу можно решить двумя способами, либо через подзапрос, либо джоинами.
215 1890851
>>1869616 (OP)
Котаны, у меня есть доступ на удаленный сервак, я могу там подключаться к местной БД (postgresql) и читать оттуда данные, но мой юзер не имеет права ничего создавать, редактировать или запускать на том серваке. Я пытался выгрузить все данные из одной таблицы, но окно терминала наебнулось и попросту не захотело выводить мне результат (не может отформатировать или хрен его знает что), как мне вывести этот результат куда-то, где я смогу гарантированного его просмотреть? файлы там создавать я не могу
216 1890858
217 1891143
>>1888482

>> Вау! Чё реально, не более трех таблиц, у реляционной модели произвольной сложности? Как на пикрил, скажем.


>да. таблица объекты(аттрибуты),


>таблица их значений,


>и таблица для связи объектов между собой.


>к этому можно свести абсолютно любую реляционную модель.


Есть где-то наглядный пример, ну или можете ли наварганить по быстрячку,
чтобы очевидно было как третью таблицу строить, ну и первую тоже.
Может если прохавать это, то можно будет сразу оптимизированные модели данных строить,
и базы данных на них уже делать, оптимизированные?
218 1891515
>>1869616 (OP)

>Есть где-то наглядный пример, ну или можете ли наварганить по быстрячку,


Я сам впервые об этом услышал, это прикольно, но, вроде, элементарно, сделай сам.
219 1891894
>>1891515
Я же писал, что я не представляю себе даже как строить эти таблицы.
220 1892853
>>1891143

> Может если прохавать это,


чтобы прохавать это нужно нормальную книжку прочитать где написано про нормализацию.

> наварганить по быстрячку,


как-то так
OBJECTS(ID, TITLE)
VALUES(OBJECT_ID,VALUE)
OBJECT_TO_OBJECT(OBJ1_ID, OBJ2_ID)

> то можно будет сразу оптимизированные модели данных строить, и базы данных на них уже делать, оптимизированные?


наоборот, оптимизация (в плане скорости доступа) подразумевает нарушение нормальных форм. почему монга быстрая? потому что данные в ней ненормализованы вообще. например: есть страница с сообщениями, у каждого сообщения есть автор, у каждого автора есть ник в системе, идентификатор, дата рождения и т.д.

монга хранит это как огромный JSON, и информация об авторе будет храниться в нем столько раз сколько сообщений он оставил, даже если на 100 постов всего один автор, то информация о нем хранится сто раз.

это очень быстро читается - один запрос к базе и ты выгрузил сразу всю информацию о странице и хуйнул ее на рендер.

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

даже индексы, это с точки зрения теории нарушение нормализации, так как в них хранится информация о данных из таблицы, т.е. происходит их дублирование. они нужны чтобы ускорить доступ к данным но создают проблемы при их сохранении/обновлении.

но индексы - это приемлемо и затраты на их перестройку с лихвой покрываются их преимуществами. а вот хранить всю инфу в виде JSON - это в большинстве случаев неприемлемо и как только монга разрастается до неприличных размеров с нее мигрируют например на постгрес (где впрочем тоже есть поддержка жсон, так что даже скрипты для миграции под это дело есть готовые)

короче секрет успешной БД - это грамотное нарушение нормализации

> Котаны, у меня есть доступ на удаленный сервак,


а доступ через что? если есть возможность пробрось порты через путти например и подключайся на своей локальной машине через pgadmin или через любую иде к котрой привык.
220 1892853
>>1891143

> Может если прохавать это,


чтобы прохавать это нужно нормальную книжку прочитать где написано про нормализацию.

> наварганить по быстрячку,


как-то так
OBJECTS(ID, TITLE)
VALUES(OBJECT_ID,VALUE)
OBJECT_TO_OBJECT(OBJ1_ID, OBJ2_ID)

> то можно будет сразу оптимизированные модели данных строить, и базы данных на них уже делать, оптимизированные?


наоборот, оптимизация (в плане скорости доступа) подразумевает нарушение нормальных форм. почему монга быстрая? потому что данные в ней ненормализованы вообще. например: есть страница с сообщениями, у каждого сообщения есть автор, у каждого автора есть ник в системе, идентификатор, дата рождения и т.д.

монга хранит это как огромный JSON, и информация об авторе будет храниться в нем столько раз сколько сообщений он оставил, даже если на 100 постов всего один автор, то информация о нем хранится сто раз.

это очень быстро читается - один запрос к базе и ты выгрузил сразу всю информацию о странице и хуйнул ее на рендер.

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

даже индексы, это с точки зрения теории нарушение нормализации, так как в них хранится информация о данных из таблицы, т.е. происходит их дублирование. они нужны чтобы ускорить доступ к данным но создают проблемы при их сохранении/обновлении.

но индексы - это приемлемо и затраты на их перестройку с лихвой покрываются их преимуществами. а вот хранить всю инфу в виде JSON - это в большинстве случаев неприемлемо и как только монга разрастается до неприличных размеров с нее мигрируют например на постгрес (где впрочем тоже есть поддержка жсон, так что даже скрипты для миграции под это дело есть готовые)

короче секрет успешной БД - это грамотное нарушение нормализации

> Котаны, у меня есть доступ на удаленный сервак,


а доступ через что? если есть возможность пробрось порты через путти например и подключайся на своей локальной машине через pgadmin или через любую иде к котрой привык.
221 1893889
существует ли что то типа автоподборщика команд как в ЯП?
222 1893936
я нихера не понимаю тип данных...
вот допустим имена-это символы,возраст-числа
те char and int
а нахрена цифры(длина?) после типа?
что есть varchar?
223 1894126
>>1893936
У тебя же не может быть возраст 99999999999, вот и ограничиваешь, сколько цифр у тебя максимум в числе. Ну а для char аналогично указываешь, сколько символов в строке максимум. Char же отличается от varchar тем, что char всегда физически занимает максимум места, даже если хранишь пустую строку, а varchar столько, сколько реально в нём хранится + 1 байт для признака конца строки.
224 1894128
>>1893889
Автодополнение? БД-шная консолька в IDEA умеет такое, но не идеально. Возможно, в DataGrip тоже это есть.
225 1894175
>>1892853

>> наварганить по быстрячку,



>как-то так


>OBJECTS(ID, TITLE)


>VALUES(OBJECT_ID,VALUE)


>OBJECT_TO_OBJECT(OBJ1_ID, OBJ2_ID)



Хм... Разве этого достаточно? Если взять за "объекты" - таблицы,
а за "аттрибуты объектов" - столбцы этих таблиц,
то глядя на эту картинку: >>1888475 ,
можно видеть, что объекты не просто связаны между собой,
а связаны через различные, конкретно-указанные аттрибуты.

То есть, там должна быть не просто табличка для связи объектов (по аналогии - таблиц),
но ещё и аттрибутов объектов (по аналогии - конкретных столбцов таблиц).
А если ещё строки в таблицах связаны, или конкретные значения???
Тогда эта табличка всевоможных взаимосвязей, она, должна бы быть - пиздец какой многомерной, разве не?
226 1894224
>>1893936
В зависимости от типа СУБД varchar может быть неоптимально хранить или индексировать. Когда поле небольшое и фиксированной длины с ним проще выстроить эффективную работу.
227 1894412
>>1894126
а зачем тогда подтипы int?
228 1894549
Аноны, объясните пж, когда использовать serial, когда sequence, когда auto_increment? И что такое constraint? Это все в psql
229 1894596
>>1869616 (OP)
В Постгрес если я удаляю таблицу (DROP TABLE) то мне потом отдельно надо будет удалить индексы к ней привязанные и CONSTRAINTS? Или они автоматом удалятся?
230 1894620
>>1894596
Автоматом.
https://www.postgresql.org/docs/8.1/sql-droptable.html

> DROP TABLE always removes any indexes, rules, triggers, and constraints that exist for the target table

231 1894622
>>1894620
Однако sequence он не снимает
232 1894627
>>1894549
Автоинкремента в постгресе нет, serial сам за него всё делает. и он неявно создаёт sequence.
233 1894729
Чем мария дб отлич от майскл?
234 1894744
>>1894175
Бамп! Как строить третью таблицу?
235 1894858
>>1869616 (OP)
Пусть есть две таблицы:
|idA|A| (int, text)
|idB|B| (int, text)
и пусть есть третья таблица для связи их:
|id|idA|idB| (int, int, int)
В ней - только id'ы, числами (INT).

Как с помощью SQL, показать таблицу |A|B| (text, text) ?
236 1894871
>>1894858
Всё, понял. Надо два INNER JOIN:

SELECT TableA.A, TableB.B
FROM TableAB
INNER JOIN TableA
ON TableA.idA = TableAB.idA
INNER JOIN TableB
ON TableB.idB = TableAB.idB;
237 1894885
>>1894871
>>1894858
А можно как-то, без особого пердолинга, сделать так,
чтобы эта таблица была таблицей в базе,
и при вводе значений (A, B),
чтобы автоматически добавлялась запись в первые две таблицы,
и взаимосвязь этих записей - в третью таблицу?
238 1894899
А как доставать жсон-подобную инфу из sql бд? Просто вот допустим надо взять из таблицы С статус, он достается через джойн С с А. Также через джойн А и Б достается 1000 рядов допустим там заказчиков из таблицы Б через связь с заказом А.

В таком тупом примере получается, что уже надо два запроса. И что, потом их склеивать через язык программирования при формировании жсона? Джойн С с А и
Б на похуях получается бредом, там этот статус будет один на весь заказ А. Полагается использовать всякие функции по возврату жсонов и массивов в постгресе чтобы одним запросом все нормально получить?
239 1895597
>>1869616 (OP)

>pics


Анимебляди уже заябали чесслово

мимо олд
240 1896507
>>1895597
Олды заебали уже чесслово

мимо аниме
241 1896508
>>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, должны добавиться записи дополнительные,
чтобы там появились новые значения, которые может вводить только сам админ базы данных этого вот Пентогона.
И главное, чтобы без пердолинга!! А то я уже заибался с этими таблицами.
Я ЩА ВОЛОСЫ НА ЖОПЕ СИБЕ ПАРВУ, ПАМААААААГИТИ!!!
241 1896508
>>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, должны добавиться записи дополнительные,
чтобы там появились новые значения, которые может вводить только сам админ базы данных этого вот Пентогона.
И главное, чтобы без пердолинга!! А то я уже заибался с этими таблицами.
Я ЩА ВОЛОСЫ НА ЖОПЕ СИБЕ ПАРВУ, ПАМААААААГИТИ!!!
242 1897110
С наступающим.
А сложно вообще создать БД с 5 таблицами новичку через workbench?
243 1897120
>>1897110
Легко.
244 1897356
>>1897110
делай через консоль
245 1897379
>>1897356
это сложно
246 1897610
>>1897379
бд с 5 таблицами с простым наполнением-изи
247 1898032
>>1897610
Нет. Это сложно...
248 1899284
>>1869616 (OP)
Как вставить 1000 строк в цикле?
249 1899292
>>1899284
-- Oracle
BEGIN
FOR I IN 1..1000 LOOP
INSERT INTO YOURTABLE (YOURCOLUMN) VALUES (YOURVALUE);
END LOOP;
END;
250 1899337
>>1899292
Бля, не пашет, тут SQLite, хуй знает как вставить 1000 ракет в эту >>1896508 таблицу Rockets...
251 1899384
>>1899337
Включаешь транзакцию и вставляешь в цикле, хуле. Потом в конце коммит.
Через insert values (), (), () лучше, конечно, но это надо руками крафтить, если не лень.
252 1899386
>>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 замыкаются,
и оно ошибки бьёт.
252 1899386
>>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 замыкаются,
и оно ошибки бьёт.
253 1899387
>>1899384
Я сделал проще, тупо javascript'ом в цикле, сгенерировал в консоли браузера пиздатое полотнище из кучи команд,
и в виде одного SQL-запроса, исполнил, и оно заполнилось.
Ракеты пока не полетят, не ссыте. Я их просто нацелил.

Но что если их терабайт будет, этих запростов ебучих?
Хотелось бы цикол, но ракет куча, а в сиквелайте у рекурсивных петель - синтаксис какой-то нипанятный.
oww.PNG6 Кб, 267x132
254 1899390
255 1899392
>>1899386
SELECT * FROM t2
JOIN t1 t11 ON t2.id1=t11.id
JOIN t1 t12 ON t2.id2=t12.id;
256 1899401
>>1899392
А можно как-то без звёздочки, чтобы не все поля, вылазили, а то там их просто огромная куча.
257 1899410
>>1899401
Ну так и напиши вместо звездочки, какие тебе нужны, алиасы все есть.
t2.id, t11.name, t12.name и т.д.
258 1899420
>>1899410
О! Заебись, сразу запахало, как надо. Оставлю пример: http://sqlfiddle.com/#!5/caeb9/2
259 1899986
>>1869616 (OP)
Возможно ли связать таблицу,
с таблицей,
которой нет, в базе данных,
но которая может быть образована из других,
уже существующих, и взаимосвязанных таблиц?
260 1900063
>>1899986
Через view
261 1900964
народ посоветуйте годной литературы по ораклу именно по администрированию, как правильно разворачивать master slave роли настраивать бекапы, архивлоги и т.д.
cryptocurrency-exchange.PNG88 Кб, 1130x549
262 1901240
>>1869616 (OP)
Вкатываюсь в проектирование баз данных,
со своим SQLite Expert Professional (x86) portable.
Цель - заебенить криптобиржу.
Пока что получился пикрил, хз можно ли оптимизировать это...

>>1900063
Я так понял, view, позволяет просмотреть таблички, которых нет, при помощи SQL-запросов.
Погуглил чуток, нашёл возможность создать view'ы, и создал их, вставляя SQL-запросы туда.
До этого, я хранил все SQL-запросы к базе - в отдельной таблице (|id(int)|Operation(text)|SQLRequest(text)|),
как та несвязанная табличка, на пикрил.

Вопрос.
А можно ли как-то СВЯЗАТЬ,
другие несвязанные, или новые таблицы,
с таблицами, генерируемыми этими вот view'aми?
263 1901245
>>1896508
Можете ниссать, это был прикол.
А то какие-то шныри c пеленгатором, здесь,
шманали вчера под дверями,
один даже в окно пытался залезть,
но сорвался и вышел в окно.

А другой с перепугу обосрался, и убежал,
а перед тем ещё и, засранец, дверь говном обмазал,
и написал: АНБ + ФБР = ♥
264 1901491
>>1901240
Ты как-то непонятно изьясняешся. Есть ключи, делаешь вью с джоинами. Не понял в чём вопрос.
265 1901519
как описать float 3.14?
266 1901520
>>1901519
NUMBER (1, 2)
267 1901522
>>1901520

> NUMBER (3, 2)


Fix
268 1901523
269 1901524
>>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.
270 1902072
>>1896508
С такой постановкой задачей, просто иди нахуй. В твои стену текста вчитываться никто не будет. Если хочешь чтоб тебе помогли, формализуй задачу коротко.
image.png16 Кб, 580x147
271 1902234
>>1869616 (OP)
Имеется таблица playlists с полями playlist_id, views и ещё какими-то.
Нужно выбрать все записи для плейлистов с максимальным суммарным значением views.
Написал запрос, который делает то, что мне нужно (пикрил), можно ли его упростить? Не делаю ли я в нём какой-то хуйни?
272 1902283
Анон, помоги!
Чищу mariadb, удаляю по сотне тысяч записей каждые несколько минут, база худеет, но занятое место на диске только возрастает уже который день. Почему так и как это пофиксить?
273 1902305
>>1902283
OPTIMIZE TABLE
274 1902535
>>1902305
База подвиснет и станет недоступной? 100 гигов и 600млн записей.
Надолго?
275 1902573
>>1902535
Не знаю, я с такими объемами не сталкивался. Гугли.
276 1902633
каково применение и смысл составных ключей?
277 1902678
>>1902633
На практике почти всегда вместо них юзают суррогатный ключ (id). Значения сразу нескольких колонок сопоставляют только в сложных джойнах и селектах.
278 1902699
>>1902678
допустим есть колонка Фамилия и к ней привязать примари ки
в чем профит?
279 1903351
Аноны, есть один сервис, с клиентами по всему миру, есть БД - Постгрес11. Я правильно понимаю, что единственный путь это мультимастер и установка нескольких серверов с БД в различных локациях и юзерами?
Планирую для начала 3 таких локации и связать их звездой при помощи Bucardo.
280 1903401
>>1902072
То был пример с толстотой. Тащемта я уже разобрался, решение - view'ы с триггерами.
281 1903482
>>1869616 (OP)
а манга из 1 пика есть на русском?
282 1903786

>MariaDB [users]> select name,city,age from users where city='London' and age=43;


Empty set (0.001 sec)

почему не работает или я не в том направлении копаю?
283 1903790
>>1903786
У тебя нет записей с city = 'London' и age = 43.
284 1903793
>>1903790
есть.
но я наверно не верно готовлю
условие и and применимы только к одной строке?
285 1903799
>>1903793
а блять,должно быть наличие этого в одном поле
286 1903827
MariaDB [users]> insert into users
-> (balance)
-> value(200.20);
Query OK, 1 row affected (0.104 sec)

MariaDB [users]> select*from users;
+----+---------+--------+------+------------------+---------+
| id | name | city | age | email | balance |
+----+---------+--------+------+------------------+---------+
| 1 | Oleg | Berlin | 26 | huaAzyANUSyahs:EooPUNCTUMcZKSom | NULL |
| 2 | Ivan | London | 19 | hu_LNy22ANUSyi@.ahooPUNCTUMco_.jm | NULL |
| 3 | Mariya | London | 19 | huy3&1i3ANUSyah*frooPUNCTUMckySom | NULL |
| 4 | Jhon | Boston | 43 | hIf+er22ANUSyaho@seoPUNCTUMcomDfm | NULL |
| 5 | sergey | anapa | 12 | huAw+y12ANUSyz07ahooPUNCTUMcHMRom | NULL |
| 6 | Egor | anapa | 30 | huy9g@67ANUSy75HahooPUNCTUMcPhzom | NULL |
| 7 | Gunther | Berlin | 32 | hu6iAy222ANUSyo@TahooPUNCTUMcjv;om | NULL |
| 8 | NULL | NULL | NULL | NULL | 200.20 |
+----+---------+--------+------+------------------+---------+
8 rows in set (0.001 sec)
почему я обломался?
287 1903839
>>1903793

> условие и and применимы только к одной строке?


Подобных ограничений нет.
>>1903799
Похоже, тебе нужен OR вместо AND.
288 1903844
>>1903827
все,я понял ошибку
надо было заполнять через update
Снимок экрана (36).png124 Кб, 1366x768
289 1903862
>>1903839
все равно не врубаюсь
290 1903868
>>1903839
ОR сработал,вывел 2 строки где есть нужное условие
но не врубаюсь в AND
291 1903902
>>1903868
OR выбирает записи, где выполняется хотя бы одно из условий (либо юзер из Лондона, либо ему 43 года, либо и то и то одновремено). AND - когда выполняются оба (юзер из Лондона и ему при этом 43 года)., то есть строка отсеивается, если хоть что-то не подошло.
292 1903925
>>1903902
начало доходить,те эти данные должны быть связаны
допустим все Иваны из города Москва
а если OR он вывалит и всех иванов(из всех городов) и всех москвичей ?
293 1903945
>>1903925
Да.
Если знаешь теорию множеств, то думай об AND как о пересечении множеств, а об OR - как об объединении.
294 1904329
SELECT КодЗаказчика, Название, Телефон
FROM Заказчики
WHERE NOT EXISTS
(SELECT*
FROM Заказы
WHERE Заказы.КодЗаказчика = Заказчики.КодЗаказчика);

Я не могу понять как это работает. Помогите
295 1904455
>>1904329
У тебя между where и not exist ничего не пропущенно?
296 1904501
Как вставить функцию в шаблонизированную строку запроса?
Поле 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"
297 1904523
>>1900964
Томас Кайт - "Oracle для профессионалов
298 1905011
Блядь, открыл первое (рейтинговое) упражнение на sql-ex и сразу охуел. Я только синтаксис прочел, а тут...

Дима и Миша пользуются продуктами от одного и того же производителя.
Тип Таниного принтера не такой, как у Вити, но признак "цветной или нет" - совпадает.
Размер экрана Диминого ноутбука на 3 дюйма больше Олиного.
Мишин ПК в 4 раза дороже Таниного принтера.
Номера моделей Витиного принтера и Олиного ноутбука отличаются только третьим символом.
У Костиного ПК скорость процессора, как у Мишиного ПК; объем жесткого диска, как у Диминого ноутбука; объем памяти, как у Олиного ноутбука, а цена - как у Витиного принтера.
Вывести все возможные номера моделей Костиного ПК.


Помощи не прошу, просто хочу узнать может там как-то по нарастающей сложности задачки есть?
299 1905031
>>1905011
А, все, нашел что к чему. Интерфейс конечно там пиздец. Не сразу понял как выбирать сложность и номер заданий. Сначала значит надо пройти обучающий этап со всеми остальными, а потом уже если захочется рейтинговый.

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

Видимо после sql-ex'a надо литкод идти дрочить.
300 1905750
>>1904523
ну такое, слишком много пространной теории и мало практики по настройке скажем мастер и слейв баз данных
301 1905761
Я снова на связи
Как проэктировать бд с 2-3 таблицами,это к теме foreign key
image.png26 Кб, 986x187
302 1905932
>>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 - блоб
Работать с такими данными очень неудобно, но всё ещё возможно.
303 1905934
>>1905932
Разумеется, сиквенсов, триггеров, констреинтов и индексов так и остаётся 100500 штук.
304 1906536

>MariaDB [users]> insert into users2020


-> values('Arthur','Moskow','49','pizdwGga111ANUSgmaiigjlPUNCTUMcoC&&m','2000','her2021');
ERROR 1136 (21S01): Column count doesn't match value count at row 1
MariaDB [users]>
что не так?
305 1906563
>>1906536
Там же написано. Если количество не совпадает, то пиши список колонок после таблицы.
Снимок экрана (37).png180 Кб, 1366x768
306 1906567
>>1906563
я не указал id c инкриментом и авто timestamp
307 1906581
>>1906567
Ну вот и впиши список без первой и последней колонки.
Откуда оно знает, что ты там имеешь в виду?
308 1906586
>>1906581
так уже делал
там написано
309 1906588
>>1906586
или способ без перечисления не работает?
по инструкции так же можно делать
310 1906617
>>1906588
Если значений не столько же, сколько колонок в таблице, то нужно перечислять.
311 1906659
Вы на память все помните?
312 1906902
Короче, двач, помоги. Пишу учебное приложение, тип клиника. Там у врача есть время когда он принимает.

Допустим он может принимать с понедельника по пятницу с 9 до 12 и с 13 до 17, а в субботу только с 9 до 12.

Вопрос. Как мне в SQL хранить такое чудо, как хранить перерыв?

Если так подумать, по-хорошему график должен быть меняющийся, чтоб он мог на каждую неделю заново делать.

Всё что мне пришло в голову:

1. Таблица доктор
2. Таблица "неделя графика", указывающая на 1 доктора.
3. Каждый день недели это два таймстампа.

Но тут вопрос, как сделать 2 перерыва? Вот ж блять, ребят подскажите)))
313 1906908
>>1906902
Можно так:
VRACH_SCHEDULE
- ID INTEGER
- VRACH_ID INTEGER -> VRACHS.ID
- DAY DATE
- INTERVAL_BEGIN TIME
- INTERVAL_END TIME

Пример:
1 | 1 | 11.01.2021 | 09:00 | 12:00
2 | 1 | 11.01.2021 | 13:00 | 17:00
..
9 | 1 | 15.01.2021 | 09:00 | 12:00
10 | 1 | 15.01.2021 | 13:00 | 17:00
11 | 1 | 16.01.2021 | 09:00 | 12:00

И пусть у врача хоть по 10 перерывов в день.
314 1906912
>>1906908
Бля, а не плохо. А можно ли запилить констрейнт чтобы нельзя было пересекающиеся записи делать?
315 1906928
>>1906912
Можно написать триггер с проверкой, триггер будет перед инсертом/апдейтом селектить существующие записи и проверять. Либо вообще вынести проверку на уровень самого приложения.
316 1907058
>>1906912
Можно запись делать через merge.
317 1907072
>>1894729
ну, в mariadb есть query cache.
и в целом, они более повернуты к людям.
318 1907095
Гуглил тут книжки по Postgres и набрёл вот на эти.
https://postgrespro.ru/education/books
Сам пока не читал, но, может, кому пригодится.
А ещё есть вот это:
https://edu.postgrespro.ru/
319 1907111
Поясните плес, почему SQL настолько уёбищный язык? Пока что это все
320 1907112
>>1907111
а что не так?
есть предложения?
321 1907119
>>1907112
Уебанский синтаксис, а именно структура запросов, произвол в пихании куда попало ключевых слов лишь бы это было похоже на английский и все такое.
322 1907120
>>1907119
а как надо?
323 1907122
>>1907120
как в нормальных языках. например, если есть
WHERE xxx IN ( arg1, arg2,...)
то, блядь и делать
WHERE xxx BEETWEN ( arg1, arg2)
а не хуйню
WHERE xxx BEETWEN arg1 AND arg2
как оно сделано
Мало того, что меняется сигнатура по сути одной семантики - ограничения области, так еще и зачем-то вхуячено слово, которое и так уже используется как логическая операция в этом же, блять, языке, не говоря уже обо всех других
То же самое еще в куче мест, например FROM-INTO и т.д.
324 1907129
>>1907119

>лишь бы это было похоже на английский


В этом и была цель при разработке sql - чтобы он был максимально похож на естественный язык и на нём могли писать запросы простые людишки. Собственно, с этой задачей он более-менее справился.
325 1907133
>>1907122
Ну, наверное, between может быть только между двумя значениями, а в кортеже их может быть больше двух, что может вносить путаницу.
326 1907141
>>1907133
Конечно, может. Но гораздо большую путаницу вносит как раз разный тип синтаксиса для по сути одного и того же.
>>1907129
Естественный язык тем и плох для разработки ПО, что он сравнительно не строгий, и в нем все пихается плюс минус рандомно, лишь бы тупая нейросеть в кожаном мешке могла это понять, а если что переспросить.
Плохо сделали, ящитаю.
327 1907185
>>1907141

>разный тип синтаксиса для по сути одного и того же


Between - это бинарный оператор, а у IN операндов может быть больше (или меньше) двух, не помню как это одним термином называется. Это если с точки зрения программиста смотреть. С точки зрения нормиса всё ещё логичней - как в английском, так и в sql.

>он сравнительно не строгий


Так и есть. Но именно это и нужно было - чтобы "пользователи ПК" не переучивались мыслить как кодеры, а могли использовать знание своего языка для написания запросов (не знаю, насколько это в реальности нужно было, просто пару раз читал такое обоснование). То, что это стало стандартом - ну, так получилось, теперь мы с этим живём. Меня, например, конкретно синтаксис не очень сильно беспокоит в sql.
328 1907194
>>1907185
Это называется арностью операции. И вот как раз вызов операции в любом ЯП должен быть, если ЯП не уёбищный, организован типовым, унифицированным, образом.

>Так и есть. Но именно


Ну, какова бы история не была этого вопроса, суть не меняется: SQL как язык - уёбок. И все им пользуются только потому что он привычен, да и вообще маленький, типа, можно и выучить всё это нагромождение тупой хуйни наизусть, игнорирую то что это куча завязанных в узел костылей. Я что-то особо не знаю юзеров SQL, которые по совместительству не программисты на более божеских языках, и по сути поэтому можно заключить, что идея обосралась на корню.
329 1907198
>>1907122

> как в нормальных языках


Скажи это дедам полвека назад.
SQL - это легаси, с которым приходится жить. Давно придумали, все смирились с синтаксисом, написано дохуя кода и литературы с использованием SQL, это всё хрен выкинешь. Да и ради более модного синтаксиса никто и подавно этого делать не будет.
330 1907211
>>1907194
Sql - не ЯП же, значит можно.

>все им пользуются только потому что он привычен


Ага, а привычен потому, что все его учат. А учат, потому что привычен...

>Я что-то особо не знаю юзеров SQL, которые по совместительству не программисты


У нас есть аптечники, которые с БД работают на уровне простых select-insert-update.
331 1907223
>>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 на флешку поставить, охуенно же опенсорц, к тому же меня ещё и прёт чёт-то ото всех этих баз данных.
331 1907223
>>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 на флешку поставить, охуенно же опенсорц, к тому же меня ещё и прёт чёт-то ото всех этих баз данных.
332 1907229
>>1907211

>Sql - не ЯП


С чего? то что он не тьюринг-полный, не значит что он не ЯП. По сути любой интерфейс между взаимодействующими сущностями это небольшой ЯП.

>Ага, а привычен потому, что все его учат. А учат, потому что привычен...


Нет, просто тонны легаси-дерьма вряд ли можно уже отвергнуть, к сожалению. Схожая ситуация есть с некоторыми аппаратными архитектурами, которые уёбищные, но слишком уж распространены.

>работают на уровне простых select-insert-update.


ради этих трех операций можно и аптечнику запомнить нормальный унифицированный синтаксис вызова. В итоге вышло, что ради того, чтоб одному аптечнику удобно было пользоваться 3% языка, 999 программистов мучаются с 100% тупого синтаксиса
333 1907233
>>1907223

> Если так, то почему бы сразу не писать в нормальной, оптимальной, минимальной и удобной форме,


вместо того чтобы связывать эти таблицы в ебические сети из нафиг не нужных сущностей, которые можно описать одной лишь табличкой - пропроще?
Сначала делаешь все в "минимальной и удобной форме". Затем понадобятся проверки, что в этих таблицах поверх таблиц записи содержат только указанные столбцы и только указанного типа. Для этого создаёшь ещё таблицы со схемой, пишешь много сложных триггеров и понимаешь, что заново изобрел таблицы с ебическими сетями сущностей, но лишним слоем абстракции.
334 1907243
>>1907223

>А пока, на SQLite, я тут, просто заебенил - простенький ToDo-list


Такую ёбу лучше на JavaScript сделать, в виде одного JSON-объекта, плюс LocalStorage, так будет ещё и доступнее, в браузере.
Там же нет множества таблиц связанных, просто одна табличка, которая может быть в один объект записана, и ещё один view, который может быть веб-мордой для объекта.
335 1907249
>>1907233
Мне почему-то кажется, что критерием оптимизации
самой вот реляционной модели данных,
является именно дублирование данных, в различных таблицах.
Ведь, в пределе, как я понимаю,
всё можно свести к банальным, взаимосвязанным между собой,
спискам уникальных элементов - таблиц с одним полем,
группируя их в таблицы по общему признаку.
Ну а дальше уже, просто таблицы с числовыми ссылками на эти вот уникальные элементы списков.
Каждое новое поле для таблицы с большим числом столбцов - это лишь новая таблица, свазанная с предыдущей - 1 к 1.
И так, короче, куча таблиц получается, в каждой из которых по одному полю.
В основном, это таблицы с цифрами, которые не занимают дофига памяти,
а вот уникальные элементы, они просто в таблицах-списках, один раз записаны, и не дублируются нигде.

Так, мне видится, оптимизированная модель данных,
но всё-же, ебическая куча таблиц - это не четыре таблицы, и не одна. Хотелось бы чё-то более универсальное, оптимальное, и конечно же - минимальное.
Чтобы один лишь раз, нужные данные, в базу данных, забить, сделать их ридонли, как-то защитить, и не ебать уже мозг излишним их дублированием.
336 1907295
>>1907249
Не всё в реляционной модели сводится к оптимизации. Например, существование констреинтов не уменьшает дулбирование, но из этого не следует, что оно не нужно. То же самое с разделением сущностей и контролем типов на уровне СУБД.
337 1907360
>>1907249
Я мимопроходил и понимаю, что ты шизик, но желаю тебе счастливого Cartesian Explosion при джойне твоего оптимизированного говна.

Ну и вообще, твоё видение оптимизации странноватое. Что-то уровня демосценного байтоёбства. На деле важнее перфоманс, поэтому в реальных проектах часто прибегают к денормализации схемы БД.
338 1907635
>>1907360
На деле, всё просто. Вот есть схема данных, таблицы и их взаимосвязи. Если её с нуля строить, всё-как бы норм, пара таблиц, и пара связей.
Но если наславать и усложнять всю эту хуйню, появляется хуева куча таблиц и куча связей, целая сеть ебучая, как сеть петри и нейросеть, в которой уже хуй разберёшься, без аккуратног сдвигания окошек, которые уже не лезут в окно схемы данных, и без отслеживания связей между этими вот - таблицами ебучими.
Нахуй нужно столько таблиц, и связей между ними?
МОЖНО КАК-ТО ПОПРОЩЕ?
Вот основной вопрос, который задаёшь себе, при проектировании сложной модели данных.
Следующий вопрос... А что насчет оптимизации? И/или нормализации? В нормализацию я не могу, ибо я не изучал все эти отношения и реляционную алгебру между ними,
у меня тупо таблички и связи, здесь.
И вот число табличек и число связей, надо бы как-то уменьшить.
И внезапно, анон, говорит, что можно описать любую реляционную модель тремя таблицами (или четырьмя, или даже одной, той, god_table),
но ибаццо с такими данными через хуеву кучу триггеров, мягко сказать, не нормально. Значит база нихуя не нормализована, данные не имеют нормальную форму.
Но я же, узрел, в трех таблицах (ну или четырех, блядь, которые так и не гуглятся), результат нормализации ЛЮБОЙ СХЕМЫ ДАННЫХ, и как-бы даже УНИВЕРСАЛЬНУЮ МОДЕЛЬ ДАННЫХ, в которой можно уместить ЛЮБУЮ МОДЕЛЬ.
Отсюда и понос этот весь.
339 1907662
>>1907360

>На деле важнее перфоманс, поэтому в реальных проектах часто прибегают к денормализации схемы БД.


Я так понимаю. денормализация ведёт к дублированию данных, или просто растёт сложность модели данных, в смысле число таблиц и свзей между ними?
Потому что, как я понял, из примера анона >>1905932
с его универальной одной, общей, god_table,
одна таблица, получается, это хорошо и прекрасно,
но внутри неё данные - дублируются пиздец как.
И если снизить дублирование данных,
придётся делать таблицы-списки с уникальными элементами,
и на них уже ссылаться из других таблиц,
а значит растёт число таблиц и число связей между ними,
и усложняется схема данных - то есть растёт сложность самой этой вот - реляционной модели данных.
Хотя да, растёт перформанс, ведь при записи/обновлении, достаточно обновить одно значение, а не делать кучу INSERT и UPDATE, ну а чтение достаточно закешировать, да и всё на этом.
340 1908077
>>1907662
>>1907635
Без негатива, но я даже не вижу, что тут нам можно обсудить. Ты тратишь время на какую-то эзотерику уровня Brainfuck. Просто рекомендую этого не делать.

>>1907635

> Но если наславать и усложнять всю эту хуйню, появляется хуева куча таблиц и куча связей, целая сеть ебучая, как сеть петри и нейросеть, в которой уже хуй разберёшься


Хотя, тут остановлюсь.

> если наславать и усложнять всю эту хуйню


А если не наслаивать и не усложнять, то получается уже по-другому. Думал об этом?

Везде, где я работал, были микросервисы (я молодой и времена монолитов не застал), и у каждого микросервиса была своя БД. Обычно в БД микросервиса не больше десяти таблиц. Это позволяет немного декомпозировать сложную схему большой БД и разделить ответственность (как между отдельными частями проекта, так и между командами разработчиков).

Плюс ко всему, часто по схеме БД можно увидеть доменные модели сервиса. Я стараюсь первым делом строить схему БД, когда выкатили функциональные требования и начали выкатывать макеты интерфейса (если есть) для новой фичи. Если ТЗ не очень хорошее, то уже на этом этапе возникает куча вопросов.

Модель данных -- это очень важная часть решения задачи, она твой помощник и она фундамент твоей работы. Ты пытаешься от неё отказаться и называешь это какой-то оптимизацией, но фактически это эзотерический эксперимент, и оптимизирует он что-то в том же смысле, в каком коронавирус оптимизирует население страны.
341 1909294
>>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...
И вот так, число таблиц и связей, может расти, они наслаиваются пиздец как, сеть растёт же, база растёт...
Может быть ещё одна модель данных в базу данных встроена, в том числе и сложная - ещё одна растущая сеть...
Ты говоришь, лучше сделать много БД, с моделями попроще...
Однако, куча баз данных, это ещё хуже чем куча таблиц в одной БД, особенно если это серверная СУБД.
Это чё, бля, на каждую базу по серверу впиливать?

>Модель данных -- это очень важная часть решения задачи,


>она твой помощник и она фундамент твоей работы.


>Ты пытаешься от неё отказаться и называешь это какой-то оптимизацией,


>но фактически это эзотерический эксперимент,


>и оптимизирует он что-то в том же смысле, в каком коронавирус оптимизирует население страны.


нет, нет, тут не совсем так ты меня понял. Я пытался выбрать именно оптимальную структуру БД, и понять как строить - на базе неё любые модели данных.
Хотя, впрочем, я описал уже выше, в этом посте, как, к этому, я подошёл.
341 1909294
>>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...
И вот так, число таблиц и связей, может расти, они наслаиваются пиздец как, сеть растёт же, база растёт...
Может быть ещё одна модель данных в базу данных встроена, в том числе и сложная - ещё одна растущая сеть...
Ты говоришь, лучше сделать много БД, с моделями попроще...
Однако, куча баз данных, это ещё хуже чем куча таблиц в одной БД, особенно если это серверная СУБД.
Это чё, бля, на каждую базу по серверу впиливать?

>Модель данных -- это очень важная часть решения задачи,


>она твой помощник и она фундамент твоей работы.


>Ты пытаешься от неё отказаться и называешь это какой-то оптимизацией,


>но фактически это эзотерический эксперимент,


>и оптимизирует он что-то в том же смысле, в каком коронавирус оптимизирует население страны.


нет, нет, тут не совсем так ты меня понял. Я пытался выбрать именно оптимальную структуру БД, и понять как строить - на базе неё любые модели данных.
Хотя, впрочем, я описал уже выше, в этом посте, как, к этому, я подошёл.
wtvr.png719 Кб, 817x2781
342 1909694
>>1909294
Ля какой тип.

> тут не совсем так ты меня понял


К сожалению, я тебя понял лучше, чем ты понял меня.

> насколько я понимаю, реляционная модель выбрана как основная, именно из-за универсальности своей...


Реляционная модель была выбрана из-за того, что суровые матанщики создали мощный теоретический фундамент, на котором можно было строить СУБД, которые бы не проёбывали данные и давали кучу гарантий при правильном использовании. Это не 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. Это эзотерика и брейнфак. Реляционки такое делать позволяют, реляционная теория -- нет.

> что показалось мне весьма охуенным, ведь если любую реляционную модель,


можно представить в некоей универсальной форме,
Ну, думаю, я тебе немного проиллюстрировал, что ты не особо понимаешь, какие именно проблемы реляционные СУБД решают и думаешь вообще не в том направлении, рискуя проебать кучу времени на хуйню и стать чуваком с пика, чего я тебе не желаю.
wtvr.png719 Кб, 817x2781
342 1909694
>>1909294
Ля какой тип.

> тут не совсем так ты меня понял


К сожалению, я тебя понял лучше, чем ты понял меня.

> насколько я понимаю, реляционная модель выбрана как основная, именно из-за универсальности своей...


Реляционная модель была выбрана из-за того, что суровые матанщики создали мощный теоретический фундамент, на котором можно было строить СУБД, которые бы не проёбывали данные и давали кучу гарантий при правильном использовании. Это не 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. Это эзотерика и брейнфак. Реляционки такое делать позволяют, реляционная теория -- нет.

> что показалось мне весьма охуенным, ведь если любую реляционную модель,


можно представить в некоей универсальной форме,
Ну, думаю, я тебе немного проиллюстрировал, что ты не особо понимаешь, какие именно проблемы реляционные СУБД решают и думаешь вообще не в том направлении, рискуя проебать кучу времени на хуйню и стать чуваком с пика, чего я тебе не желаю.
image.png15 Кб, 782x203
343 1910384
Сап!
Супер-быстрый low-iq вопрос по SQL:
База данных - в формате, как выделено зелёным на скрине.
Как написать запрос, чтобы результат был как выделено синим на скрине?
344 1910396
>>1910384
Это не получится простым sql запросом. Надо какие-то анальные расширения или в коде собирать.
345 1910449
>>1910384
Использование одной таблице несколько раз в одном запросе с внутренним соединением?
346 1910465
>>1910449
Хех, я предполагал что-то такое, но без понятия, как это сделать.
Мог бы кто-нибудь написать запрос для примера со скрина? А далее я смогу перенести на свою задачку.
sql.png19 Кб, 1321x659
347 1910478
>>1910465
Сделала на коленке.
Последний групп и лимит костыль чтобы показывало по одной записи.
Можно сделать красивше, но это уже сам додумай.
348 1910488
>>1910478

>Сделала на коленке


умница! теперь выкладывай сисечки.
349 1910489
>>1910488
Опечатался
Могу тебе только хуй за щеку скинуть
350 1910514
>>1910478
Спасибо!
Только с "далее я смогу перенести на свою задачку" я погорячился, походу, лол (:
351 1910522
>>1910489
себе скинь, педрила криворукий
352 1910951
>>1910384

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
353 1911261
Сап, sqlач.
Кроме sql-ex, какие есть сайты с задачками по sql?
Менее припизднутые, чем на sql-ex.
354 1911277
>>1909694
Мол, в 35 лет чел знает все понемногу и нихуя на уровне профессионала?
355 1911321
>>1911277
В смысле, что он просто отбитый.
356 1911497
>>1910384

create table justtest
(
letter vrachar(5),
digit int(2),
name varchar 10,)

insert in table justtest(letter,digit,name)
values (a,1,'арбуз')
values (a,2,'банан')
values (a,3,'виноград')
values (b,1,'инжир')
values (b,2,'киви')
values (b,3,'лимон')

SELECT [letter], [1],[2],[3]

FROM [dbo].[justtest]

PIVOT (max(names)for digit in ([1],[2],[3])

) AS test_pivot
357 1911519
>>1911261
Sql academy
Но задачки не оч сложные
358 1911537
>>1909694

>Графовая модель, например. На реляционки она натягивается примерно как сова на глобус, сейчас для этого обычно используют что-то вроде ArangoDB. Там есть ACID и нет SQL, кстати.



https://ru.wikipedia.org/wiki/Графовая_база_данных#Описание

>Для задач с естественной графовой структурой данных графовые СУБД могут существенно превосходить реляционные по производительности, а также иметь преимущества в наглядности представления и простоте внесения изменений в схему базы данных.



Но там не сказано, что графовая модель несовместима с реляционной. Это так, или всё-же можно преобразовать любую графовую модель в реляционную, и реляционная модель достаточно универсальна, чтобы представить ею - абсолютно любую модель, в том числе и графовую?
Пусть сложно, пусть не очень наглядно, но всё же...
359 1911539
>>1911537
Что-то вроде одной таблицы связей вершин графа, с указанием там направления этих связей и силы этих связей может поместиться в реляционную модель, я думаю.
Но если так мозги описывать, например, с их 100 миллардами нейронов, и по 10000 связей по каждому ихнему дендриту их, каждый-с-каждым, то пиздец получается какой-то,
пиздатая таблица многие-ко-многим, c 1000 триллионов строчек, и ещё и весовые коэффициенты надо указать, в отдельном поле у неё.
Охуенный граф.
360 1911541
>>1911539
Если он ещё и двунаправленный, надо будет ещё и направление связей указать, это ещё одно поле с 1000 триллионами значений.
361 1912062
>>1911537

> или всё-же можно преобразовать любую графовую модель в реляционную


Можно вообще любое говно преобразовать в типа-реляционное, это выше обсуждалось. Это будет работать, но это будет неправильно, потому что ты потеряешь свои концептуальные и логические модели данных, оставив только физическую и используя СУБД как серверный Excel для хакеров.

> не сказано, что графовая модель несовместима с реляционной


Понятие совместимости очень растяжимое. До 1999 года в стандарте не было рекурсивных запросов и CTE, поэтому чистый SQL не позволял делать некоторые графовые запросы. Нужно было на PL/SQL расписывать свою процедуру для рекурсивных запросов, то есть пиздец. Сейчас со всеми костылями можно графы в БД обходить, но это всё ещё медленно и мало где приемлемо. Реляционки могут хранить какое угодно говно, могут обрабатывать какие угодно запросы, но будут эффективны только в реляционных задачах. Чуда нет.

Погугли, что ли, курсачи какие-нибудь по проектированию БД. Там должны быть расписаны шаблонно все этапы. Если ты не совсем ещё потерян, то поймёшь, что у тебя не должна God Table получиться после концептуального и логического этапов проектирования.
362 1913481
>>1910384
Listagg.
363 1913624
>>1869616 (OP)
Согласно принципам архитектуры Фон-Неймана,
в частности, согласно "принципу однородности памяти",
команды (инструкции) и ДАННЫЕ,
хранятся в одной и той же памяти.

>Команды и ДАННЫЕ хранятся в одной и той же памяти и внешне в памяти неразличимы.


>Распознать их можно только по способу использования;


>то есть одно и то же значение в ячейке памяти может использоваться и КАК ДАННЫЕ,


>и КАК КОМАНДА, и КАК АДРЕС в зависимости лишь ОТ СПОСОБА ОБРАЩЕНИЯ К НЕМУ.


>Это позволяет производить над командами те же операции, что и над числами,


>и, соответственно, открывает ряд возможностей.


>Так, циклически изменяя адресную часть команды,


>можно обеспечить обращение к последовательным элементам массива ДАННЫХ.



Я знаю, что SQL не является Тьюринг-полным языком программирования,
и вообще, вроде как, это даже и не язык программирования,
хотя, также как HTML, CSS и XML, он - обладает всеми свойствами,
позволяющими классифицировать его, как декларативный язык программирования.

Вопрос. А возможно ли, внутри базы данных,
хранить в виде данных - адреса и команды для обработки этих вот данных,
и сделать из базы данных, полноценное приложение, могущее в тьюринг-полноту,
а значит и в реализацию абсолютно любых программ, которые можно исполнить на компе?
То есть, блядь, ну, то, что адреса и команды, можно в таблички записать, это понятно,
но можно ли сделать это самодостаточным, или же надо какую-то ёбу и расширение дополнительное,
чтобы оно ИНТЕРПРЕТИРОВАЛО по-разному эти вот ДАННЫЕ, либо как ДАННЫЕ, либо как КОМАНДЫ, либо как АДРЕСА,
и чтобы ОНО, это расширение, как-бы ДОПОЛНЯЛО, всю хуйню, которая не является тьюринг-полной,
а является какой-то НЕПОЛНОЙ, блядь?
363 1913624
>>1869616 (OP)
Согласно принципам архитектуры Фон-Неймана,
в частности, согласно "принципу однородности памяти",
команды (инструкции) и ДАННЫЕ,
хранятся в одной и той же памяти.

>Команды и ДАННЫЕ хранятся в одной и той же памяти и внешне в памяти неразличимы.


>Распознать их можно только по способу использования;


>то есть одно и то же значение в ячейке памяти может использоваться и КАК ДАННЫЕ,


>и КАК КОМАНДА, и КАК АДРЕС в зависимости лишь ОТ СПОСОБА ОБРАЩЕНИЯ К НЕМУ.


>Это позволяет производить над командами те же операции, что и над числами,


>и, соответственно, открывает ряд возможностей.


>Так, циклически изменяя адресную часть команды,


>можно обеспечить обращение к последовательным элементам массива ДАННЫХ.



Я знаю, что SQL не является Тьюринг-полным языком программирования,
и вообще, вроде как, это даже и не язык программирования,
хотя, также как HTML, CSS и XML, он - обладает всеми свойствами,
позволяющими классифицировать его, как декларативный язык программирования.

Вопрос. А возможно ли, внутри базы данных,
хранить в виде данных - адреса и команды для обработки этих вот данных,
и сделать из базы данных, полноценное приложение, могущее в тьюринг-полноту,
а значит и в реализацию абсолютно любых программ, которые можно исполнить на компе?
То есть, блядь, ну, то, что адреса и команды, можно в таблички записать, это понятно,
но можно ли сделать это самодостаточным, или же надо какую-то ёбу и расширение дополнительное,
чтобы оно ИНТЕРПРЕТИРОВАЛО по-разному эти вот ДАННЫЕ, либо как ДАННЫЕ, либо как КОМАНДЫ, либо как АДРЕСА,
и чтобы ОНО, это расширение, как-бы ДОПОЛНЯЛО, всю хуйню, которая не является тьюринг-полной,
а является какой-то НЕПОЛНОЙ, блядь?
364 1913638
>>1913624
Перечитал этот пост, и чё-то от прочитанного на ум приходит следующее...
Вот короче есть процессор, с его тьюринг-полнотой, и есть RAM, хранящая ДАННЫЕ.
Есть, короче режим загрузки, когда в процессе загрузки ГУДИТ тьюринг-полный проц,
а есть, значит - режим гибернации или режим сна,
которые просто записывают состояние RAM на жесткий,
а при выходе из "ждущего" и "спящего" режима - c жесткого диска, память просто втекает в RAM, и этот вот тьюринг-полный процессор, он - не гудит дохуя.

Короче, сразу на ум спадает, просто записывать в базу данных, BLOB'ами, результаты вычислений,
и если надо процу произвести вычисление с инструкции 1 по инструкцию 2,
то, можно было бы - просто считать из значения BLOB,
в базе данных,
уже готовый результат вычислений, как ДАННЫЕ,
вместо того, чтобы вычислять всю эту хуйню.

Это походит на что-то вроде кэширования... Но нет, это не совсем то.
Вопрос скорее в том, возможно ли наславивать неограниченное количество закэшированных данных, в базе данных, так,
чтобы производить минимум вычислений тьюринг-полным устройством?
Если возможно, то возможно ли, после всего этого, произвести оптимизацию и нормализацию данных так, чтобы ужать базу данных с этими вот закэшированными BLOB'ами, в минимальные размеры, и чтобы она была оптимальной эта база данных,
а не раздута до ебических размеров?
Что-то вроде универсальной логической схемы для конкретного приложения, имеющей минимальный размер. Что-то вроде скомпилированной программы, но внутри базы данных.
365 1913641
>>1913624
Если язык не является тьюринг-полным, то нельзя, какие абстракции в рамках языка ни строй, абстракции всегда ещё более ограниченные, чем сам язык наверняка это как-то связано с теоремой Гёделя о неполноте, но мне как-то пох.
Впрочем, пишут, что SQL тьюринг-полный, если юзать рекурсивные запросы.

> расширение


Расширениями можно хоть пустое множество Ø сделать тьюринг-полным. Так можно прийти к хранению исходного кода хоть на питоне в БД и запуске его в питоньем интерпретаторе с помощью этого расширения.
366 1913643
>>1913638
Ясен хуй, что если результаты вычисления могут быть разбиты на части атомарные, которые уже есть в базе данных, то проще эти результаты вычисления не писать BLOB-ами ебическими,
а вписать внутрь реляционной БД - в виде таблиц, и записей в таблицы, по которым легко и просто найти результат,
вместо того, чтобы его вычислять.
И как-бы по частоте использования, уже, обращаться к этим записям, и отсортировать их внутри таблиц, и взаимосвязать заебато.
367 1913645
>>1913641

>Расширениями можно хоть пустое множество Ø сделать тьюринг-полным.


>Так можно прийти к хранению исходного кода хоть на питоне в БД и запуске его в питоньем интерпретаторе с помощью этого расширения.



Так вопрос был в том, будет ли вся эта ёба,
более оптимальной по размеру,
из-за её реляционости универсальной,
которая может быть оптимизирована и нормализирована.
Или же не будет?
Всё-таки, скомпилированные программы, имеют малый размер, и являют собой ничто иное как ДАННЫЕ на жестком диске/флешке/SSD, а вот уже СПОСОБ ИСПОЛЬЗОВАНИЯ этих данных,
при запуске программ этих вот, скомпилированных,
делает из них ПРОГРАММЫ, а не просто ДАННЫЕ
(которые, как я подозреваю, могут быть и в базе ДАННЫХ,
и не просто EXE-шники, BLOB'ами, блядь,
а в реляционных базах данных,
то есть, в виде реляционных данных, какой-либо реляционной модели программы, и тупо - в виде таблиц и связей между ними).
Ясное дело, что в виде таблицы можно любой HEX-код расписать,
как в HEX-редакторах он и выводится, таблицей.
Но такой способ хранения - не очень оптимальный, как по мне.
В общем, взглянул так, на всё это, и думаю, быть может удсться найти что-то прорывное, и невъебенное здесь.
368 1913655
>>1913645

> будет ли вся эта ёба, более оптимальной по размеру, из-за её реляционости универсальной, которая может быть оптимизирована и нормализирована.


Не будет. Нормализация - это не способ абсолютного сжатия данных до возможного минимума. Даже архиватор порой справится лучше.

> СПОСОБ ИСПОЛЬЗОВАНИЯ этих данных, при запуске программ этих вот, скомпилированных, делает из них ПРОГРАММЫ, а не просто ДАННЫЕ


Да, и ничего сверх этого здесь не выдумать. SQL-запросы - это просто один из способов использования данных, и даже если суметь заставить СУБД читать "команды" из таблицы и выполнять их, это концептуально ничем не отличается от того же процессора, выполняющего команды над данными в ОЗУ.
369 1913678
>>1913655

>Нормализация - это не способ абсолютного сжатия данных до возможного минимума.


>Даже архиватор порой справится лучше.


Кстати, я уже думал над этим, то есть над сжатием данных, с помощью "реляционной модели данных",
и думал, в контексте "принципов построения Кодов Хаффмана": https://ru.wikipedia.org/wiki/Код_Хаффмана
"Код Хаффмана", позволяет сжимать данные, оптимально кодируя их,
а именно - представляя символы различными, короткими кодами, в зависимости от частотности использования их,
причём так, чтобы символы встречающиеся наиболее часто,
кодировались более короткими кодами, которые в итоге - встречаются чаще более длинных кодов.

Кодирование Хаффмана, сводится к построению двух (трех) таблиц из уникальных элементов:
1. Таблица символов, отсортированных по частоте их встречаемости.
2. Таблица кодов Хаффмана.
3. Таблица для связи символа из первой таблицы и кода (связь 1 к 1, поэтому опционально).
Для морзянки, например, несколько символов могут иметь один и тот же код, поэтому эта, третья таблица, тут кстати,
ведь связь между уникальными кодами и уникальными символами, уже - многие-ко-многим.

Ну так вот, о чём я речь вёл? Ах да... Сжатие данных, с использованием реляционной модели.
Выше, вот здесь: >>1907249
я пришёл к тому, что любую реляционную модель,
можно представить таблицами-списками,
содержащими только уникальные элементы (и пары их).

Если так, то очевидно то, что наиболее часто-встречающиеся,
и наиболее часто-использующиеся данные, в базе данных,
в том числе и большой, должны бы, в результате оптимизации,
иметь ID не надцать трильйонов, а 1, чтобы меньше данных хранить,
а остальное говно, неуникальное, должно бы быть вычищено нахуй из базы данных,
и если оно имеет место быть в каком-либо месте,
то оно может быть просто - представлено ссылкой на уже имеющуюся запись.

И вот так, оставляя лишь уникальные элементы, и связи между ними - можно было бы сжать даже пиздейшую "базу данных".
потому что связи, это просто связи, там не так много инфы надо, чтобы сохранить только их
(два элемента, направление связи между ними, и опционально ещё - сила связи).
Всё это может поместиться в одну табличку, и ебись оно конём.
Это намного пижже, вместо того, чтобы расписывать дохуя дублирующихся данных,
дуя теми же BLOB'ами, базу данных до пиздейших размеров.

Это я, так, примитивно смотрю.
Возможно существуют ещё более крутые алгоритмы оптимизации баз данных, и их минимизации,
и возможно даже, какой-то базоданный алгоритм, невъебенный, можно было бы использовать,
ВНЕЗАПНО, для эффективного сжатия НЕСЖИМАЕМЫХ ДАННЫХ. Мне откуда знать?
Это скорее математики и профессора, наверное, шарят лучше, в этом направлении...
А я, как-бы, издаля поглядываю на всё это, со своим неполным пониманием, и всё-таки, чё-то, да вижу уже.
369 1913678
>>1913655

>Нормализация - это не способ абсолютного сжатия данных до возможного минимума.


>Даже архиватор порой справится лучше.


Кстати, я уже думал над этим, то есть над сжатием данных, с помощью "реляционной модели данных",
и думал, в контексте "принципов построения Кодов Хаффмана": https://ru.wikipedia.org/wiki/Код_Хаффмана
"Код Хаффмана", позволяет сжимать данные, оптимально кодируя их,
а именно - представляя символы различными, короткими кодами, в зависимости от частотности использования их,
причём так, чтобы символы встречающиеся наиболее часто,
кодировались более короткими кодами, которые в итоге - встречаются чаще более длинных кодов.

Кодирование Хаффмана, сводится к построению двух (трех) таблиц из уникальных элементов:
1. Таблица символов, отсортированных по частоте их встречаемости.
2. Таблица кодов Хаффмана.
3. Таблица для связи символа из первой таблицы и кода (связь 1 к 1, поэтому опционально).
Для морзянки, например, несколько символов могут иметь один и тот же код, поэтому эта, третья таблица, тут кстати,
ведь связь между уникальными кодами и уникальными символами, уже - многие-ко-многим.

Ну так вот, о чём я речь вёл? Ах да... Сжатие данных, с использованием реляционной модели.
Выше, вот здесь: >>1907249
я пришёл к тому, что любую реляционную модель,
можно представить таблицами-списками,
содержащими только уникальные элементы (и пары их).

Если так, то очевидно то, что наиболее часто-встречающиеся,
и наиболее часто-использующиеся данные, в базе данных,
в том числе и большой, должны бы, в результате оптимизации,
иметь ID не надцать трильйонов, а 1, чтобы меньше данных хранить,
а остальное говно, неуникальное, должно бы быть вычищено нахуй из базы данных,
и если оно имеет место быть в каком-либо месте,
то оно может быть просто - представлено ссылкой на уже имеющуюся запись.

И вот так, оставляя лишь уникальные элементы, и связи между ними - можно было бы сжать даже пиздейшую "базу данных".
потому что связи, это просто связи, там не так много инфы надо, чтобы сохранить только их
(два элемента, направление связи между ними, и опционально ещё - сила связи).
Всё это может поместиться в одну табличку, и ебись оно конём.
Это намного пижже, вместо того, чтобы расписывать дохуя дублирующихся данных,
дуя теми же BLOB'ами, базу данных до пиздейших размеров.

Это я, так, примитивно смотрю.
Возможно существуют ещё более крутые алгоритмы оптимизации баз данных, и их минимизации,
и возможно даже, какой-то базоданный алгоритм, невъебенный, можно было бы использовать,
ВНЕЗАПНО, для эффективного сжатия НЕСЖИМАЕМЫХ ДАННЫХ. Мне откуда знать?
Это скорее математики и профессора, наверное, шарят лучше, в этом направлении...
А я, как-бы, издаля поглядываю на всё это, со своим неполным пониманием, и всё-таки, чё-то, да вижу уже.
370 1913774
Как в один if несколько операторов засунуть?

Делаю:
IF УСЛОВИЕ
EXEC govno @jopa1,@jopa2
EXEC zalupka @jopa1,@jopa2

Первый exec отрабатывет внутри if,а второй будто он идёт после, внезависимости от условия if. Что не так?
371 1913775
>>1913774
А всё, успех. BEGIN...END
372 1913815
Зачем указывать foreign key при создании таблицы? Есть преимущество от того что ключ забит жёстко, а не просто логическая связь?
373 1913851

>обновился mysql


>Version 8.0.23 has no release notes, or they have not been published because the product version has not been released.



Ахуеть.
Ну готовьте анус для уязвимости века!
374 1913853
>>1913815
Эхо старой войны между программистами и дба.
В принципе все промышленное IT - это борьба с долбоебизом и случайными ошибкам.
В программе Laba1.pas или научном исследовании, где из долбоебов один ты - можешь не создавать.
375 1913886
>>1913678
>>1913815
Ты всё же потерянный и несёшь прямо полную хуетень.
376 1913918
>>1913815
Например, чтобы ON DELETE CASCADE работал.
377 1916951
Сап, котятки. Поясните, насколько плохо пользоваться такими штуками как констрейнты и не дублировать их в коде?

То есть по сути бизнес логика в базе данных. Учитывая что навешивание бизнес логики происходит в миграциях и под контролем версий.

Ну или там занесение сохранёнок через миграции? Где-то у вас в продуктах так делают, или на петухоне всё пишут связанное с бизнесой, а максимальный констрейнт это unique?
378 1916972
>>1916951
Да, максимум проверок в БД - это NOT NULL/UNIQUE/REFERENCES. Хз насчёт общепринятых причин считать логику в БД чем-то плохим, но как минимум такое неудобно дебажить + проверки в коде всегда можно по-быстрому переписать без новых скриптов миграции.
igor-bogdanov-s-telefonom-1.jpg28 Кб, 500x500
379 1917036
Сосоны, если я решил 50 задач полностью сам включая 3 и 4 уровень на скл-ех в разделе обучения, можно начинать поиски позиции джуна аналитика с предположением, что я достаточно знаю мат стат и теорвер?
380 1917083
381 1917153
как назначить сущ колонке с эиейлами уникальный ключ?
382 1917158
>>1917153
не надо уже
383 1917213
>>1916972
Почему дебажить неудобно? Тестики написал, тестики выполняются.

Да, поменяются спецификации и докидывать миграцию которая дропает констрейнт и хуярит новый, но в чём сложность отладки-то?

Я предпочитаю иметь имя таблицы которая меняется в моей миграции. По имени найти можно. Да и тесты поменялись, по тестам видны требования.
384 1917220
>>1917213
Как через дебаггер подключиться к базе? Никак.
Тестики укажут, что есть ошибка, но не объяснят, в каком месте она возникает. Если у тебя большая и сложная бизнес-логики, где что-то сеттится в разных местах и в зависимости от условий, что-то копируется, что-то не копируется, без дебаггера охуеешь её искать.
385 1917257
>>1917220

Пля, чел, вы чё прям дебагеры прям с jdb юзаете, ходите по строчульками и стек чекаете? Писец параша, норм пацаны же TDD хуярят.

Ща бы код ООП дебажить покрытый юнит и фичер тестами
386 1917264
>>1917257
Посмотрю я на этот TDD в проекте на 500К строк с постоянно горящими сроками.
387 1917270
>>1917264

Сроки горят чаще всего на дебаге. Тебе дают заказывают фичу. Ты её имплементишь. Во время заэстимейченное на эту задачу входит написание тестов. Оно прогнозируемо.

А время дебагинга бывает очень разное, его невозможно спрогнозировать и чаще всего заэстимейтить тоже.
388 1917280
>>1917270

> Оно прогнозируемо.


Конечно, всего-то 100500 человеко-дней на полное покрытие всех возможных кейсов.
389 1917300
>>1917280
Та ты преувеличиваешь, пишут на ТДД и заебись живут. Почитай Мартина, Мартин дело говорит.
390 1917322
>>1917300
Ну, у нас тесты пишут только для определённых случаев, в целом код ими мало покрыт, но на написание времени уходит много. Да и даже когда они падают, причину всё равно приходится искать дебагом, ибо что-то прийти может из непокрытого кода из метода на 200 строчек (лол).
Мартина в закладки добавляю.
391 1917467
>>1916951
Смотри, расклад такой. Сохранёнки не юзай. Сохраненки говно.

Проблема в чём, проблема в том что львиная доля data intensive приложений о том как должны выглядить данные. И тебе придется огромную часть кода сувать в СУБД.

А PL язык хуже, чем какой-нибудь питухон, руби, пхп, жава.

В нём просто не будет тех фич, не будет однострочной хуйни, не будет библиотечек и тд.

Примитивный язык.

> констрейнты



Смотри, если это закон логики, там типа в таблице хранится промежуток времени в виде 2х дат. То тут констрейнты это хорошо.

А если там бизнес логика которая может меняться, то нет. Пример - у нас есть сайт соцсеть. Минимальный возраст для регистрации - 13 лет. Но тут Путин выпустил закон что, нельзя до 15 лет.

То есть у тебя в базе уже есть невалидные данные, прикинь как охуенно.

Это должно отсекаться в валидаторе, ясен хуй.

>>1917322
А дело в том что ТДД - это другое. Там ты пока пишешь тест лучше, поймешь хуле тебе надо сделать. В итоге ты просто дольше печатаешь. Но ты ещё пойми что в ебучих скриптоязыках всё это говно удобно сделано ибо там иначе сложно, а какой-нибудь JUnit неудобный пиздец.

Ещё, проекты очень большие это хоть и правда жизни, но это плохо. Надо разбивать на маленькие.
392 1918441
>>1917036
Да x2. Сам примерно так и нашёл.
DsMrnDLWoAAYA2V.png123 Кб, 309x407
393 1918866
Аноны когда нужно заниматься поддержкой индексов? Вот допустим есть таблица с внекластерным индексом, новые значение поступают регулярно, если удаляются данные, то всегда только самые старые, обновлений нет.
Нужно ли при таком раскладе обслуживать индексы? Насколько я понимаю переиндексацию надо делать если данные обновляются/удаляются за промежуточный период, если с краёв накидывют, то и так работает. или я не прав?
394 1919787
Кто-нибудь может помочь с простой для меня неподъемной задачей аля создать мини-базу данных в SQL? Я неебу как это работает, у меня не работает ничего, я проебала всю теорию и все практики, а нужно сделать экзамен

Хелп плис :(
395 1919796
>>1919787
CREATE DATABASE hui;
396 1919842
>>1919787
Съебалась отсюда.
397 1919845
>>1919796
А collation? Как же длину хуев сравнивать?
398 1920171
в вебе примари кей кому обычно назначают кроме id?
эмейлу,фамилии?
399 1920183
Сап, двач. Плез подскажи, какая в sqlite3 есть возможность сравнить 2 даты и получить разницу в минутах(секундах) при запросе?
400 1920189
>>1920183
В нем нет дат. Хранишь юникс таймштампы и считаешь разницу в секундах.
401 1920192
>>1920171
Обычно даётся id-шнику.

Делать email PK не очень хорошо по следующим причинам.
1) Сравнение с ID это очень частое сравнение, сравнивать строки дольше чем циферки
2) Связывать таблицу с другими по эмайлу это лишняя морока, хранишь больше данных и дольше джойны
3) Заёбы с апдейтом. Допустим ты захочешь поменять ID. Тебе придётся делать сложные апдейты(связанные таблицы). Вообще изменять ID не советуют. Даже если твой софт не позволяет менять email, фамилию-то можно поменять? Тянучки замуж выходят так-то.
402 1920196
>>1920192
а уник лучше дать мылу?
403 1920240
>>1920196

Ну если у тебя по логике он должен быть уникальным, то да.
404 1920256
>>1920240
еще вопрос.
я щас колупаюсь с внешними ключами
как лучше назвать колонку из табл сообщений с внешним ключом,если он ссылается на id пользователей? также ?
405 1920286
>>1920189
У меня дата, вернее время в строке hh:ii
406 1920287
почему не удаляются таблицы?
407 1920290
>>1920287
разобрался
408 1920291
>>1920256

Обычно называют user_id

Если у тебя таблицы

users
- id
- name
- email
- img

и

comments
- id
- thread_id
- user_id

То обычно так называют.
409 1920295
>>1920286

Псс, можно не отвечать. Решил в пизду, запрошу оба поля из SQL и в php вычту разницу.
410 1920464
>>1869616 (OP)

> - Разбираемся, почему PostgreSQL - не Oracle



А поясните популярно почему PostgreSQL круче MySQL и чем Oracle круче обоих
411 1920508
>>1920464
В оракле есть MERGE, и больше нигде его нет. Это всё, что нужно знать.
412 1920795
>>1920464
На оракле можно разориться
413 1920835
>>1920508
смысли нигде нет? Там какой-то особенный merge?
414 1920841
>>1920835
И мускле и постгресе только убогий insert ... on duplicate key update/on conflict do update.
415 1920874
>>1920841
В mssql есть merge. Гугл говорит в постгресе тоже.
416 1920890
>>1920874
Ого, тогда постгрес и правда оракл.
417 1921740
Анон, привет, юродивый челом бьет, подскажи, как переписать данное условие на AND и OR, и что вообще за форма записи такая:
SELECT * FROM demo
where (name, id) >= ('limit', 5)
418 1921793
Пацаны выручайте, мне нужно БЫСТРО вкатиться в SQL и вообще базы данных, ничего по этому не знаю вообще, кроме синтаксиса, тестовое горит, посоветуйте курсы, видосы с ютаба, книжки, что угодно вообще, онегай!
419 1921813
>>1921740
Называется row constructor, в данном случае сравнивается попарно.
Т.е. name >= 'limit AND id >= 5
420 1921945
>>1921793
Советую.
Безымянный-файл-изображения-(172)-5.jpg80 Кб, 640x640
421 1922224
>>1921945
Спасибо, хули.
422 1923324
Какую бд выбрать вообще? Есть какой-нибудь гайд годный?
Нашел списочек nosql https://hostingdata.co.uk/nosql-database/ но там просто пиздец, перебирать это.

Нужно небольшая, маленькая, околореялционка (типо дополнительные поля v), само kv и дерьмо уровня graph/doc/bson. Чтобы всё это было acid.
А еще чтобы оно распределённое было. И маленькое, а не 5мб постгреса. А еще чтобы можно был на клиентском устройстве базу держать, синхронизировать с серверами и в локальной сети строить acid, лол, но это манямечты
Ну и офк без интерпрайс версий, когда функционал обычной версии специально обрезают.

Такое есть вообще? Или это влажные фантазии?
423 1923715
>>1923324
SQLite, долбоёба ты кусок.
424 1923726
>>1923715
Так он ж doc/kv nosql-говно хочет.
425 1923736
>>1923726
Мы все понимаем тут, что он ёбнутый. Пояснять не буду.
426 1923765
>>1923715
>>1923736
Проиграл с шизофреника. Ты в курсе сколько говна нужно поверх sqlite писать, чтобы это было пригодно на проде? Или ты кроме домашних скриптов нихуя не писал?
427 1923779
>>1923765
Ты хочешь маленькую встраиваемую БД, чтобы была распределённой и умела дохуя всего. Если кто-то из вас двоих шиз, так это точно не он.
428 1923819
>>1923779
Тут тебя тоже придется к шизиками отнести, если ты думаешь что sqlite правда можно в прод ставить. Оно максимум для встройки, да и то уже давно есть варианты получше.

А то что я описал - уже есть. Couchbase lite (вместе с сервером) тот же. Или YugaByteDB. Первый коммерческий, второй хз что там. UnQLite впринципе заебись, хуй знает, кокое-то оно страшное.
Нужно больше вариантов, но я уже заебался уже схемы составлять, то на таблицах, то на ключах, и думать куда документы в тысячи строк делать. Уублят.
429 1923999
>>1921813
Спасибо, анон! Нагуглил еще вариант названия tuple comparision
и условие правильнее будет таким:
name > 'limit or (name = 'limit' and id >= 5)
430 1924004
Ораклисты, подскажите, каким образом можно написать запрос, чтобы положить БД?
На практике такое выстрелило один раз, когда в цикле c апдейтами с промежуточными коммитами писал запрос тяжелый с 10+ left join. В итоге запрос после n итераций просто завис. Опытный админ назвал нубом и сказал, что данные читались из сегмента отката. Но как, если после каждой итерации происходит коммит?
tumblrlqrqjkW4ti1qav3uso11280.png804 Кб, 1280x720
431 1924044
>>1923819
>>1923324

> околореялционка


> типо дополнительные поля v


> само kv


> дерьмо уровня graph/doc/bson


> Чтобы всё это было acid


> чтобы оно распределённое было


> И маленькое


> прод


> шизик


> прод


> типо дополнительные поля v


> шизик


> то на таблицах


> то на ключах


> документы в тысячи строк делать


> шизик


> арод

432 1924399
Поясните за SQL сервер, креденшиалы блять, они мне нахуй не нужны эти креденшиалы ваши.
Почему я не могу просто так делать манипуляции с базой данных, мне похуй на всякие привилегии и прочую поебень, зачем мне какие-то логины и пароли?
А если я хочу свой пет проект с локальной базой данной перенести на другой комп, мне тоже придется авторизоваться на сервере? Как сделать переносимость?
Я так понимаю всякие игрули че-то пишут в дб и читают оттуда, и никакой хуйни типа введите пароль от винды? Как это вообще работает?

Ещё хотел поинтересоваться, 1 транзакция insert на 10 строк лучше и быстрее, чем 10 раз по 1 строке? Если допустим, мне нужно читать данные, скажем, из большого файла и конвеерно записывать их в базу, как эффективней это сделать?
firewalls.jpg37 Кб, 1280x251
433 1924428
>>1924399
ну потому что обычно с БД работало десктопное приложение и у каждого был свой пароль.

сейчас всем похуй, но бывает что у каждого микросервиса свой пароль.

Вообще, главная концепция Сесурити в том что, ты заранее не знаешь где именно ебанет и вынужден усложнением и избыточными перекрывающими друг друга мерами. Разве это не очевидно? как такие вопросы возникают вообще?
434 1924431
>>1924399

>Ещё хотел поинтересоваться, 1 транзакция insert на 10 строк лучше и быстрее, чем 10 раз по 1 строке?


Да.

>Если допустим, мне нужно читать данные, скажем, из большого файла и конвеерно записывать их в базу, как эффективней это сделать?


Ну так почитай документацию.
Впрочем, есть и универсальный метод:
INSERT INTO .. VALUES (..),(..),.... ;
(вроде в оракле такой синтаксис не прокатит)
435 1924475
>>1924431
Ну в смысле мне по 1 строке из файла читать и делать её инсерт в таблицу или сразу по 100 строк? Как вообще отцы такую задачу решают?
15275938450773.png364 Кб, 880x660
436 1924506
Ананасы, ткните где можно почитать про синхронизацию баз. У меня есть одно центральное remote хранилище, и несколько приложений со своими локальными базами. Как сделать чтобы в цетральной бд всегда были последние данные? Например в клиенте изменились данные, он их отправил в бд. А пото просыпается другой клиент со старыми данными, видит что в бд лежит другое и тоже обновляет, в итоге мы имеем проебтданных. Неужели к каждой записи надо добавить поле последнеего изменения и сверять каждый раз?
437 1924558
>>1924475
Включается транзакция и хуярится одним запросом много записей insert values (), (), ()
самый быстрый способ.
438 1924560
>>1924506
MariaDB Galera cluster например. Но это тебя не спасет если клиенты уходят в оффлайн, а потом снова появляются онлайн, но уже с записями, которые будут конфликтовать с записями в кластере.
439 1924707
>>1869616 (OP)
Чем вы тут занимаетесь? За это деньги можно получить?
440 1924869
>>1924044
Но ты же серьезно шизофреник. Бомбанул и гринтекст с кариночкой высрал. SQlite на проде, ору нах с шизика

>>1924506
>>1924560
Для этого есть всяческие субд и алгоритмы вроде Raft.
Гуглить и изучать через поисковой запрос "кластеры, орекстраторы", проблема называется "state machine replication".
Ничего там не конфликтует, если багов нет.
441 1924925
>>1924506
а схуяли у тебя клиент "просыпается"?
есть еще классическая круговая репликация в mysql, не galera.
Это дубовая методика, но работает. Аккуратно только таблички с engine=blackhole создаешь на каждом.
442 1924982
>>1924560
>>1924925
>>1924869

> Но это тебя не спасет если клиенты уходят в оффлайн, а потом снова появляются онлайн, но уже с записями, которые будут конфликтовать с записями в кластере.


Вот как раз это - моя проблема. У меня клиенты это приложения на ведре, пеке и тд. Они 146% онлайн изредка, когда юзер запускает это самое приложение. А данные должны быть везде одинаково.

Мне не подходит репликация, просто потому что основная база это постгрес, а клиентские - что туда запихнут создатели. Например в qt и ведре это SQLite, в других фреймворках может быть по другому.
443 1924984
>>1924982
ну и че ты приперся спрашивать как настроить субд?
это вопрос чисто организации логики кода.
пиши код.
444 1924986
>>1924984
Ну вот у меня пока идея только одна - добавить поле с датой послекднего обновления и каждый раз проверять. Но я почему-то уверен, что есть способы лучше, и люди сталкивались с такой проблемой до меня. И может быть даже выработали конкретный алгоритм решения.
445 1925209
>>1924869
Дядя, ты сам то хоть раз кластер настраивал или только в ютубе видел. Почитал я про твой raft хуйня без задач, где право на запись имеет только мастер выбранный консенсусом узлов кластера. Проблема с которой столкнулся анон называется выход из split-brain
446 1925212
>>1924986
Сделай денормализацию базы. Пусть клиенты выгружают данные в одну таблицу, загружают из другой, каждый клиент пусть еще генерит себе уникальный айдишник. На центральном постресе напиши хранимую процедуру которая будет перекладывать данные по кд из сырой таблицы в готовую для отдачи.
447 1925216
>>1925212
Возможно я не понял что ты имеешь ввиду, но как это решит проблему того что неизвестно какие данные актуальные? Клиенты ведь всегда пишут в одну сырую таблицу. Сам посуди, один клиент отправил новые данные в сырую таблицу, постегрес их скопировал в основную, а потом проснулся другой клиент, увидел что его данные не совпадают и решил отправить свои. Разве что прикрутить локальную проверку на то, были ли уже данные отправлены или нет, и если были а данные не совпадают, значит их надо скачать.
448 1925349
>>1925216
В упор не вижу необходимости клиенту что то решать. Свои выгрузил, новые скачал. Точка. А какие данные актуальные пусть решает сервер. Можно к серверу push нотификацию прикрутить, чтобы он сообщал клиентам что данные обновлены.

А у тебя как то наоборот. Клиенты выкачивают базу, потом что то мержат со своими локальными данными. Потом закачивают. А потом оказывается что пока он выкачивал и мержил, там уже другой клиент что то закачал. Ой.
449 1925360
>>1924982
Раз у тебя постгресс - смотри субд по постгрессу.
Вот тут https://github.com/zalando/patroni смотри, найдаешь всё что нужно.
Используй dcs, используй самые примитивные алгоритмы, прочитай хотя бы про них.

>>1925209

> raft хуйня без задач, где право на запись имеет только мастер выбранный консенсусом узлов кластера


> называется выход из split-brain


Сам-то чуешь что пишешь? Или ты тот шизик который sqlite собрался на сервер пихать?
Рафт это выбор лидера. Если лидер одни - всегда, гарантированно, будет одна мастер бд. Если будет одна бд - никакой несогласованности не будет. Какой еще сплитбрайн?
450 1925379
>>1925360
Я вообще мимо проходил и лишь заметил что ты далек от практики. У тебя гео распределенный кластер развалился на две части. Каждая выбрала себе мастера. Половина клиентов повисла на одном половина на другом. Потом магистральный провайдер починил оптику. И все сосалово. Хуй у тебя база сольется если там были апдейты или удаления и хуй твой раст тебе в этом поможет
451 1925560
>>1925379

> У тебя гео распределенный кластер развалился на две части


> магистральный провайдер починил оптику


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

> Половина клиентов повисла на одном половина на другом


Это уже маняфантазия про децентрализованные сети в условиях военного времени, когда межконтинентальные кабели перерезаны. О таком маняфантазируют в другом разделе.
И конечно же тут работают другие механизмы, а не raft. Он прост для продакшена сделан, а не для этих маняфантазий.

> Хуй у тебя база сольется


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

> ты далек от практики


Ну ты понел.
452 1927121
Как заставить Postgres жрать говно память?
база 70Gb, хочется чтобы хотя бы она как-то использовала память, типа как mysql, иначе зачем это всё...
453 1927138
>>1927121
так она использует. Просто ты не умеешь измерять.
Покажи как именно ты измеряешь?
Screenshot20210131200328.png58 Кб, 999x284
454 1927189
>>1927138
Она в LXC-контейнере в проксмоксе. И сам гипервизор говорит, что не ест и htop внутри тоже... Чую нужно как-то conf настроить, но там какие-то суринамские понятия, за несколько подходов не смог осилить.
455 1927858
>>1927189

>man htop:


>For Memory usage the key is:


>Green: Used memory pages


>Blue: Buffer pages


>Yellow: Cache page



ну. 11 Гб на твоей картинке заюзано. Какие-то противоречия наблюдаешь?
1611142555looped1611142554.mp4434 Кб, mp4,
268x480, 0:10
456 1928091
>>1927858

>Yellow


И правда. Вот так новости!
Спасибо!
Попросить помощи у анона.png163 Кб, 1543x681
457 1928296
Здравствуй, дорогой анон, поможешь пожалуйста с лабой по бд?
Как реализовать ветвление на er-диаграмме?
Человек, принёсший в ломбард предмет, может иметь разные цели, если например, под залог, то предмет сразу отправляется на склад, а если он уже продан, то отправляется на витрину.
Мне создать отдельную сущность для продажи/залога?
458 1928408
зачем нужна монга?
459 1928424
>>1928296
В таблицах "Склад" и "Витрина" по столбцу thing_id с ссылкой на таблицу предметов, а "ветвление" определяется наличием или отсутствием соответствующих записей.
460 1928477
>>1928424
Спасибо.
461 1928516
Сап, аноны. Есть таблица с десятками миллионами записей и она постоянно растет. У каждой записи есть уникальный ключ (то есть уже проиндексирована). Задача: прочитать записи в таблице по уникальномым ключам. Проблема: с увеличением базы - большое время ожидания. Я вижу выход только в репликации и шардинге базы. Кэширование не поможет так как постоянно выбираются разные данные, соответственно полезно в кеш попадет мало. Что можете посоветовать?
462 1928519
>>1928516
Нужно понять как делается выборка из таблицы. Она же имеет какую-то логику кроме ключей? Или ты всегда только с ключом работаешь? Например у меня есть таблица с лярдом записей, но я даю пользователю за раз получить записи только за период в 30 дней + ключ. Работает стабильно. В общем я бы подумал над логикой и архитектурой в первую очередь.
463 1928523
Сап базач.
Есть таблица в мускуле. В таблице история финансовых транзакций. Задача: найти для каждого пользователя транзакцию с наибольшей суммой.
Сейчас сделано так: делается select max(debit) as maxDebit group by customer, maxDebit, потом таблица джойнится сама на себя с условием on debit = maxDebit and t1.customer = t2.customer.
В общем эта залупа как-то работала, пока в один прекрасный день не пришло 6 лямов транзакций. Запрос благополучно сложился. Есть какой-то адекватный способ решить проблему кроме как джойнить таблицу саму на себя?
464 1928535
>>1928523
оконные функции
465 1928591
>>1928535
Ну нихуа себе. Спасибо. Пойду попробую расковырять этот запрос.
466 1928606
>>1928408
Чтобы быть популярной в 2014.
467 1928634
>>1928516

> У каждой записи есть уникальный ключ


>Проблема: с увеличением базы - большое время ожидания



вот здесь ты что-то пиздишь.
468 1928643
в чем отличие марии от майскула?
469 1928651
>>1928643
Оскал капитализма.Посрались 10 лет назад.
В основном совместимы.

Ах да, в Oracle Mysql нет query cache, в Mariadb есть.
download.jpg4 Кб, 259x194
470 1928666
>>1928643
Не посрались, а оракл купил мускл у его разработчика, а тот форкнулся и дальше себе пилит под другим именем.
471 1928671
>>1928666
но глобально это одно и тоже?
472 1928673
>>1928671
Все фичи до форка те же, а дальше развиваются по-своему. Хотя в целом для средней макаки разницы нет.
473 1928680
>>1928673
на самом деле не понятно что выбрать и где сейчас больше экспертизы в самой сути и оптимизации запросов сосредоточено.Похоже, что в Oracle.

Но Mariadb может, например , не выпиливать query cache из маркетинговых сообрежений, а делать продукт для людей.
474 1928684
>>1928680

>на самом деле не понятно что выбрать


постргес
475 1928688
>>1928684
деточка, если твой мозг не испорчен ораклом, то и эмулятор оракла для нищих не нужен.
476 1928766
>>1928634
Что не так?
477 1928772
>>1928519
Нет, получаю только по ключу, ключ интовый, уникальный. У меня 70 миллионов записей и все уже работает очень медленно.
478 1928791
>>1928766
Единичные выборки по ключу не должны тормозить.
Структура хранения b-tree лежащая в основе обычных индексов , почти линейно масштабируется.

Ты должен понять и измерить что на самом деле происходит
479 1928991
14088420736600.jpg30 Кб, 351x364
480 1929150
Сосоны, я нихуя не понял внешний ключ.
Допустим, есть две таблицы. В одной таблице банковские счета, а в другой - счета рублевые и счета валютные. В первой таблице в одном столбце все счета - и рублевые, и валютные, во второй каждый тип счёта в своём столбце. Если говорить на языке теории множеств, я правильно понимаю, что внешний ключ это подмножество (валютный или рублёвый счёт) некоторого множества (все счета), и в общем-то это отношение и является внешним ключом, где внешний ключ содержит не все строки, относящиеся к основному множеству?
Нихуя не могу найти нигде толкование такой ситуации, а всякие многие ко многим и один ко многим это не то.
481 1929161
>>1929150
Ебать ты объяснятор. ЯННП
image.png16 Кб, 524x425
482 1929184
>>1929161
Ну пикрелейтед короче. И я не понимаю, правильно ли я понял концепцию первичного ключа и внешнего ключа.
Первичный ключ - все счета. У первичного ключа нет повторяющихся значений.
Внешние ключи - валютный и рублёвый счёт. Внешний ключ это подмножество первичного ключа, то есть внешний ключ <= первичный ключ. Грубо говоря, во внешнем ключе есть НУЛЛЫ по отношению к первичному.
Всё так? Мне надо, чтоб во второй таблице типы счетов при суммировании составляли весь столбец счетов.
15854064117700.jpg93 Кб, 494x604
483 1929196
Сап базач. Нужна архитектурная помощь неофиту. Вопрос платиновый - есть декстопное приложение для прохождения тестов. У нее есть локальный (файл) sqlite. В бд есть n таблиц ответов на тесты (разная логика) по типу testNQuestions, у теста есть n вопросов, нужно реализовать "сохранение" теста при прохождении если по каким-то причинам приложение будет неожиданно закрыто.
В базе уже есть таблица с результатами (testNAnswers), только они сохраняются в конце теста. Я хочу переписать так чтобы запись с ответами апдейтилась после каждого вопроса. В таблице ответов есть одно поле - перечисление ответов, туда запихивается сериализируемый байт массив ответов у которого 2 поля - id вопроса и ответ (не записывать результаты у меня таки хватило ума).
Дальше у меня начинаются вопросы. При загрузке теста нужно определить есть ли запись или нужно начинать новый тест. В начале я подумал что нужно доставать тот лист и смотреть сходятся ли каунт листа и каунт вопросов, но это мне не совсем подходит. Дальше я подумал что мне нужно добавить флаг - пройден ли тест, но добавить поле в таблицу не совсем правильно т.к. у меня шифрование/безопасность и юзверь может залезть в файл бд и поменять флаг. Дальше я подумал что нужно этот флаг засунуть в само поле ответов, но это как-то тоже вроде криво. А - еще есть нюанс что порядок вопросов рандомно мешается и это тоже нужно записывать чтобы потом все восстановить.

Короче пока вот что я придумал - в таблице testNAnswers я добавляю поле shuffled в котором будет массив Id вопросов (рандомный их порядок), при каждом ответе в тесте будет обновляться поле массив с ответами Answers и обновляться поле Shuffled с удаленным индексом с начала. И будет таблица типа Session в которой будет храниться user id и массив строк с тестами который юзер не прошел, который будет обновляться после каждого пройденого теста удалением строки теста.
Есть какая-то более нормальная реализация этого?
484 1929206
>>1929150

> на языке теории множеств


Это термин чисто из теории реляционных бд, врядли его можно просто выразить через теорию множеств. По сути внешний ключ это способ задания функции, тоесть благодаря внешнему ключу ты ставишь в соотвествие каждому кортежу одного отношения (строка таблицы) какой-то кортеж из другого отношения (строка таблицы) тоесть у тебя получается множество пар строк из двух таблиц, тоесть функция. В классической математике требуется взаимнооднозначное соотвествие (чего в бд нет), но в теории множеств вроде такого не надо. Но при этом сам внешний ключ это не функция. Но с помощью него задается. Нормально это не назвать, хотя может я не знаю - я в математике в общем-то нуль.
485 1929219
>>1929196
Зависит от того хочешь ли ты делать бизнес-логику в бд или нет. Если нет то приложение просто после каждого ответа отдает сериализованый массив ответов базе. А при загрузке база просто отдает сериализированый массив ответов назад, а приложение уже ебется что дальше делать. Например смотрит какие вопросы еще небыли заданы и задает рандомный из незаданых. А если незаданых нет - показывает результаты теста и предлагает начать новый. А если хочешь логику в бд то там скорее всего нужно обмазываться разными триггерами и обработками, вряди ты это чисто на отношениях нормально сделаешь.
486 1929239
>>1929206
Ну, честно говоря, я не понял твой пост. Видимо, я сам термин ключ не понимаю, не говоря уж о первичных и вторичных.
487 1929372
Думаю добавлять несколько колонок в уже существующую таблицу в кликхаузе иди заделать новую таблицу и отбирать данные через join-ы. Они в кликхаузе сильно влияют на производительность при чтении?
488 1929432
Какой программой можно рисовать структуру бд?
489 1929447
>>1929432
Любой программой для рисования.
490 1929450
Аноны пытаюсь сделать следующее:
Внутри процедуры сначала положить данные во временную таблицу, а потом использовать эту таблицу в мердже. Код примерно такой

src
as
( select
from hui
)

select

into #zalupa
from src

merge dst as d

Так вот, мне надаёт это сделать подчёркивает таблицу назначения(dst), хотя если убрать финт с временной таблицей вставляет нормально. Там где-то запятых или ещё чего надо нахуярить перед мерджем?

.....
491 1929930
может ли бд прибавить 7 дней к дате создания и вычислить новую дату вдля другой колонки?
492 1929982
>>1929930
Может
493 1930158
Есть много данных (~1,5млрд записей)
Запросы будут на проверку наличия данных в БД, в достаточно большом количестве. Поэтому важна скорость.

Какую БД лучше использовать под эту задачу?
494 1930195
>>1930158
Что ты там миллиардами считаешь?
495 1930238
>>1930158
Redis.
496 1930240
>>1930238
ну сделай децимацию данных. и так 10 раз.

всегда есть что удалить и оптимизировать. даже если ты IoT-пуки собираешь.
497 1930696
>>1930238
но потребуется большое кол-во озу для всей бд
не самый лучший вариант, потому что сама бд будет весить много

>>1930240
не получится
image.png1 Кб, 314x35
498 1931235
для первичного ключа достаточно выбрать primary key?
или нужно все остальные поля тоже выбирать?
499 1931249
>>1931235
Что значит нужно? Какие тебе нужно, те и выбираешь.
Праймери в любом случае обязан быть не нуль и уникальным.
500 1931278
>>1931249
есть я его сделаю еще автоинк, это допустимо?
501 1931287
>>1931278
Конечно.
502 1931290
может ли Бд считать проценты сама?
503 1931329
[42000][2000] ORA-02000: отсутствует ключевое слово ALWAYS
Position: 75.
как фиксить?

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production - версия дб

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Feb 5 15:00:25 2021
Version 19.3.0.0.0 - моя версия
504 1931442
>>1931235
получится. Просто у тебя ПиЭма нормального не было.
505 1931585
>>1931290
Может
506 1931626
>>1931585
каким образом?
DsMrnDLWoAAYA2V.png123 Кб, 309x407
507 1931954
Сап аноны.
Есть таблица с расписанием. Переодически в неё добавляются новые отрезки, сложность в том что они могут пересекаться.

Например добавили первый отрезок 8:00-12:00 Hui, потом добавляем ещё один, 9:00-13:00 Govno, тогда в таблице должно быть 8:00-9:00 Hui и 9:00-13:00 Govno. В какую сторону копать?
508 1932343
>>1931954

> В какую сторону копать?


Вычитание. Из большего вычитаешь меньшее.
509 1933422
>>1869616 (OP)
Анон, поясни немного за ораклы.

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. И чот всё резко непонятно стало.
510 1933846
>>1932343
Спасибо аноныч.
511 1933858
>>1933846
Просто я сам туповат и придумал только условие и после условия вычитание. Туповато, ну а шо поделать
512 1934433
практическое применение триггеров какое?
513 1934808
Уважаемые, что это за синтаксис?
В FROM после названия таблицы пробел (какого хуя?)

SELECT Uri,NodeID, Caption, Node.CustomProperties.City
FROM
X.Nodes Node
WHERE
Node.CustomProperties.City = 'SPB'
514 1934867
>>1934808
Просто упущенно ключевое слово AS. Такое допустимо
>>1934433
Даты например не руками ставить.
515 1934882
>>1934867

>Просто упущенно ключевое слово AS. Такое допустимо


Хм, а зачем в данном случае тут AS вообще, ведь выборка лишь из одной таблицы?
И почему-то для CustomProperties.City принудительно указано Nodes.
516 1934883
>>1934882
Ну может раньше был еще один подзапрос, либо у человека так голова работает, либо ему так удобнее, либо он долбаеб - выбери вариант сам
517 1935052
>>1934808
Nodes -> Node.

Для читаемости WHERE-части и джоинов, так больше похоже на естественный язык. Но как и многое другое в реляционках, это дело вкуса.

>>1934882

> зачем в данном случае тут AS вообще, ведь выборка лишь из одной таблицы?


Никто тебя не ограничивает в создании алиасов.
518 1935109
Можете помочь, пожалуста? Только учу мс скл, хочу создать связь между таблицами, в чем проблема?

CREATE TABLE Customers
(
Id int PRIMARY KEY IDENTITY(1,1),
FirstName nvarchar(100),
LastName nvarchar(100),
AccountId int FOREIGN KEY REFERENCES Accounts references invalid table (Id),
PassportId int FOREIGN KEY REFERENCES Passports references invalid table (Id)
)

CREATE TABLE Accounts
(
Id int IDENTITY(1,1),
Money MONEY
)

CREATE TABLE Passports
(
Id int IDENTITY(1,1),
IdentificationNumber nvarchar not null,
DateOfRegistration DATE not null
)
519 1935512
Возможно ли из MySQL запросом получить даты, сгруппированные по минутам или часам со средними значениями за это время, независимо от того, есть ли вообще или сколько строк попадает в каждый интервал?
Помогите запросом. В постгресе вроде есть date_trunc, а вот в mysql - хз.
520 1935574
>>1935109
Ты при создании первой таблицы ссылаешься на несуществующие вторую и третью.
Или их сначала создай, или fk добавляй в 1 после создания 2 и 2
521 1936245
>>1935512
Что ж ты такой пидор ленивый? Первая ссылка в гугле.
522 1936552
Два вопроса:

Что лучше, 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

Пример с Stack overflow.
523 1936672
>>1936552
А ещё можно

SELECT from table1 t1
JOIN ON ///
and status='Open'
JOIN ON ///

Если в двух словах, есть нюанс с фильтрами, если фильтруишьт при джоине, значения вобще непопадают в результирующую, а если в WHERE, то попадют но будут отфильтрованы. Какзалось бы однохуйственно, но при left джоине разница будет.
524 1936683
>>1936672

Ну так чё пижже, маняподзапрос или манявер?
525 1936719
>>1936672
Или 3 варик самое то?
526 1936878
>>1936552
Ну так ты с какой точки зрения спрашиваешь? С точки зрения перформанса джойны лучше
527 1937204
Здарова базаны. Я - мимозалётный тостер, нихуя не админ В теории, есть запрос в pg где к очень дохуя строк делается джоин и от этого становится хуево всем вокрут.
Вопрос - можно ли разбить список с дохуя строк на мелкие бакеты и циклом всё это переджоинить? Или это вообще больная идея?
528 1937547
>>1937204
Теоритически да, можешь добавить в теории партицию, написать процедурку, куда ты будешь передавать инкремент цикла. И джойнить их по одной партиции, но это довольно странная для оптимизации запросов х-ня. Лучше индексы добавь к джойнищимся таблицам.
529 1937576
>>1937547
Спасибо, пойду с этим к своим базанам и они меня нахуй пошлют, а их манагер меня на улице отпиздит.
530 1937577
>>1937576
А чё они сами его оптимизировать не могут?
531 1937635
>>1936878
Лучше JOIN, пока не возникают трудности, потому что так читать проще.

>>1936878

> перфоманса


Нет: https://www.thinktecture.com/en/entity-framework-core/cartesian-explosion-problem-in-3-1/

Проблема не в EF, если что, а в том, что JOIN -- синтаксический сахарок для декартова произведения множеств, если я не всё ещё забыл со времен студенчества. Много джойнов -- пиздец, и надо либо денормализовывать данные, либо обкладывать всё костылями.
532 1937707
>>1937635
При этом стак и практика говорят об обратном
https://stackoverflow.com/questions/2577174/join-vs-sub-query
533 1937964
Привет, посоны.
Какие вакансии предполагают 300к/наносек и что учить?
Если серьезно, то хочется всерьёз углубиться в базы данных и интересно, каков срез рыночка на данный момент, что наиболее востребовано и какие знания нужны. Буду благодарен за советы.
534 1938146
>>1937707
У нас на тестовом контуре пару месяцев назад сервис весь постгрес сожрал, когда мы на отъебись ещё три джойна докинули. Я бы особо и не выёбывался, если бы это не случилось. Я бы даже не знал об этой проблеме, в принципе.
535 1938156
>>1938146
Возможно особенности конкретного запроса, таблиц, или среды. У меня был другой опыт. Так что все возможно.
536 1938186
Аноны, дамп базы данных весом 2.5 гб импортируется уже часа 4. Это же не нормально, да? Что в конфиге нужно править чтобы ускорить процесс? В наличии 16 гб оперативки.
537 1938452
>>1937577
Им это не нужно, а у меня кастомная задача, и таблица даже если будет - то временно. Кароч, не спринтовая тема.
538 1938655
может кто помочь в связях между таблицами разобраться? и минимально объяснить
539 1938772
>>1938655
Могут. Какой вопрос - такой ответ
540 1938778
>>1938772
я скину схему, а ты(или кто-нибудь другой) расскажет что там по связям. сижу втыкаю, и до меня не доходит что-то
541 1939047
Господа, как в оракле сделать автоинкрементный первичный ключ?
чтобы при добавлении записей он сам увеличивался?
542 1939056
>>1939047
версия оракла 11.2
543 1939066
>>1939047
Sequence + триггер на инсерт.
544 1939067
>>1939066
спасибо)
545 1939072
>>1938778
Скидывай.
546 1939074
>>1939072
можем в тг?
547 1939075
>>1939074
Неа.
548 1939130
Скажите, а лепить флаги в int поле и проверять их битовыми операциями - это распространенная практика в системах, где логика в БД?
Почему я больше нигде такого говна не видел? Ухх сука, уебал бы нахуй.
549 1939144
>>1939066
тригер лучше сделать before или after?
я сделал сначала before и проблема появилась, если я делаю два абсолютно одинаковых инсерта и у меня имеется там уникальное поле, то оно не дает заинсертить поля, но инкремент все равно прибавляется.
550 1939195
>>1939144
Перед инсертом ты можешь напрямую установить значение, оно ещё не ушло в таблицу, после инсерта уже придётся апдейтить, так что лучше перед, обычно так и делают.
В том, что инкремент прибавился даже после ошибки, ничего страшного нет. главное, что ты получишь уникальное значение первичного ключа.
551 1939242
FoundationDB использует кто? Заебись или как?
552 1939276
>>1939130
Да, это нормально. Но для меня тоже дико. На сколько я понял, это какой-то олдскульный подход. И люди его использующие, очень высокого мнения о себе. Сейчас не так актуально
553 1939312
>>1939144
Еще у embedded'ов и системщиков часто бывает, и для всяких бинарных сетевых протоколов.
Прост в сях, плюсах и современных языках общего назначения этим удобно пользоваться, а в sql - нет.
>>1939276
На больших объемах данных вполне актуально.
554 1939330
>>1939130
Всмысле, поехал что ли, эта операция минимум времени занимает
555 1939468
>>1939330
Да мне похуй на машинное время. Давай тебе вместо горсти флагов is-чо-нибудь-там дадим одно поле flag и попробуй без документации понять, что в нем хранится.
556 1939577
как сделать чтобы при вставке в таблицу подтягивались данные в нужные ячейки, есть связь есть по внешним ключам?
557 1939757
У меня база nosql(mongodb), но думаю тут так же как в sql. Нубский вопрос: в базе данных есть составной индекс по полям field1+field2. Других индексов для этой таблицы нет. Если я хочу найти в ней что-то и отсортировать по field2, этот индекс хоть немного ускорит дело, или вообще бесполезен?
558 1939794
>>1939757
Не так, как с индексом по одному полю, но ускорит.
Можешь план запросов посмотреть и убедиться, что там будет index full scan, а не table full scan.
Хотя тут еще зависит от объема данных, анализатор может забить хуй на индекс, если так будет быстрее.
Но я даун, лучше тебе подождать ответа крутанов.
559 1940046
есть какой-нибудь качественный гайд по написанию функций в oracle?
560 1940153
Мне нужно собрать из разных баз данных с разной структурой данные в одну единую БД. Исходные БД - это несколько БД на MS SQL Server, а также несколько файлов Access и SQLite.
Сначала я все нужные таблицы скачиваю с серверов как есть в файлы SQLite (для этого написал на C# утилитку, тут всё работает как надо), ну и локальные файлы прочих БД тоже в SQLite перегоняю. Затем я пытаюсь собрать всё это в единый файл SQLite.
Для этого я подключаю все SQLite файлы в один проект и пишу один большой SQL скрипт, который переводит все исходники к моей единой структуре. Этот запрос я пишу в Notepad++.
Поскольку скрипт большой и уже стал довольно сложным, мне хочется его рефакторнуть. Есть ли какой-то редактор запросов SQLite, где я могу делать переименование имён таблиц, полей и т.п. Но не просто тупой поиск и замена, а с понимаем того, что переименовываются только имена в связанных запросах и таблицах. Это есть в Visual Studio, но он понимает какой-то специфический диалект U-SQL, который отличен от SQL в SQLite. А когда Visual Studio детектит ошибку, функция переименования отключается.
Что посоветуете?
561 1940231
>>1939130
Часто это очень удобно, а также однозначно повышение производительности и снижение размера БД.
Ключевое тут обеспечить документируемость. Потому что даже самому через пол года будет сложно разобраться, что ты там в битовых операциях городишь без норм. описания.
Я обычно флаговые поля помечаю в названии словом Flag и делаю табличку отдельную где каждое отдельное значение флага хранится и его название текстом.
Иногда делаю табличку с полным перебором возможных флагов и внешний ключ на неё.
562 1940265
как лучше сделать для обуви внешний ключ?
получается если артикул одинаковый, а размер разные, то это две разные записи в таблице.
если я сделаю составной внешний ключ (артикул, размер) это нормально будет работать?
563 1940288
>>1940265
А почему нет?
564 1940537
>>1940265
Cочетанию артикула и размера можно присвоить свой ID, и хранить сочетания в ещё одной табличке.
Артикул должен быть в отдельной таблице артикулов. Текстовое поле не должны быть PK.
Размер должен быть в отдельной таблице размеров. Размер может быть дробным, может быть в разных ЕИ. Размер float*4 со значением 44.5 - плохая идея для PK.
Таблица сочетаний артикула и размера имеет FK на эти две таблицы.
Таблица операций (поступление, отгрузка) ссылается на таблицу сочетаний как FK.
565 1941100
Есть одна таблица. ЕОТ
В ней есть ID и есть ParentID, который может содержать значение из поля ID этой таблицы, либо NULL, если родителя нет.
Я хочу для каждой записи прописать RootID, который будет равен либо просто ID, если у записи нет ParentID, либо же самый верхний parent.
Как это сделать запросом SQL?
566 1941245
ребят, подскажите пожалуйста, как сделать чтобы при вставке одного поля, из других таблиц подтягивались нужные мне данные в эту таблицу, естественно они связаны по ключам
567 1941332
>>1941100
recursive CTE
568 1942150
есть тригер который срабатывает после вставки строки, почему у меня он обновляет все поля в таблице, а не только той строки, которая была вставлена?
569 1942166
>>1942150
Потому что апдейту всё равно, что его вызвали из триггера. Апдейт он и в Африке апдейт. Пиши подробное условие where.
570 1943305
можно как-нибудь сделать, чтобы триггер срабатывал только когда я пытаюсь вставить в одну ячейку, а когда в >1, то нет
571 1943807
572 1944050
>>1943807
как?
573 1944285
как сделать апдейт сразу на несколько строк?
если количество строк апдейта совпадает с количество строк селекта, который и возвращает нужные значения?
574 1944885
>>1944285
update ... set ... where уникальное поле редактируемой бд in (select уникальное поле редактируемой бд from подзапрос). Вроде это должно выглядеть так.
575 1944890
Всем доброго времени бытия. Вопрос к анонам: что нужно читать, знать и понимать, чтобы стать невьебенным DBA? Сейчас пишу запросы на постгресе за средний прайс, но хочется больше монет. Хватит ли мне прочитать талмуды из ОП-поста? И как отточить эти знания на практике?
576 1944893
Посоветуйте книгу для обучения для ньюфага. В 2013-2016 годах на VS FoxPro создавал БД в визуально стиле, но понимаю что это явно не то и не совсем полноценная БД получается, но мне в принципе нравилось. А сейчас понимаю, что надо расти дальше и просто запросов с селектами явно не хватает.
577 1944919
Как размоножить одну и ту же строку?

Допустим есть таблица, мне надо чтоб одна запись превратилсясь в 10, и одно поле было N+1, для каждого члена.
578 1946594
как получить последнюю вставленную строку в oracle?
sequence в таблице нет.
579 1946620
>>1946594
Никак, оракл может вставлять строки не по порядку, из-за чего даже rownum не поможет.
580 1946818
Ньюфаг итт. Возможно ли управлять схемой базы postgres через файл, синхронизировать её с файлом? То есть у меня есть например файл в котором все мои CREATE TABLE со всеми связями, и я редактирую этот файл, а база сама под него подстраивается безо всяких альтеров. Это вообще имеет смысл, или влажные фантазии макаки-меня? Сложно просто воспринимать SQL после традиционного программирования, ты в эту хуйню скармливаешь код, и он пропадает навсегда. Хочется иметь кодовую базу, которая будет определять твою БД.
581 1946825
>>1946818
Это не имеет особого смысла. СУБД не может догадаться, как мигриррвать уже существующие в ней данные. Не удалять же всё при каждом изменении схемы.
В реальных проектах команды не вводят в консоль руками, вместо этого пишут скрипты миграции с кучей альтеров, и ничего не пропадает. Скрипты хранятся всегда и никуда не деваются, у них есть версионирование и прочее. Делают это всё разными тулзами, например, в джаве популярны flyway и liquidbase, в твоём языке должно быть что-то аналогичное.
582 1946868
>>1946825
Двачую
583 1946940
>>1946818
Гугли <dbms name> schema compare.
Для pgsql не пользовался, но для sql server'а есть ssdt schema compare в visual studio - может сравнивать 2 бд, 2 набора скриптов или бд и набор скриптов. Из разницы генерит скрипт, который можно накатить на бд чтоб устранить различия, или добавить в миграции.
Есть аналогичные штуки от redgate, devart и altova (для разных субд, в т.ч. постгрес).
Некоторые из этих тулов можно запускать из консоши без ui, для всяких ci/cd нужд.

>>1946825
>>1946868
Вот эти тулы и генерят скрипты миграции, который потом можно накатывать ликвибейсами, флайвеями и флюентмиграторами.
584 1947724
>>1946825
>>1946940

> миграции


Спасибо, аноны. Погуглил, именно то что нужно: весь дефенишон базы хранится в файлах, его можно переносить на разные компы и поднимать/опускать сколько хочешь. Чаю.
Думал миграции это только с одной СУБД на другую, или с языка на язык, или другую версию языка, всё такое.
585 1948374
Сап, двач. Пользовались ли вы GraphQL? Выглядит удобно, но знакомый сказал, синтаксический анализатор запросов работает дольше чем выполнение запросов. Может у вас был другой опыт, поделитесь
586 1948528
>>1948374
Graphql для создания API, типа rest/soap/grpc, базы данных тут не при чём.
587 1948694
Хай, аноны. Нужно создать мелкую БД в онлайне, к которой можно обращаться с запросами, потому что в голове отрисовывать результат запроса вообще не хочется. На каком ресурсе можно сделать такое?
588 1948710
>>1948694
А на локалхосте в чем проблема?
589 1948711
>>1948710
Впадлу настраивать сервер же.
590 1948712
591 1948713
>>1948711
Что настраивать? Скачать установщик и нажать next? Тебе не нужен какой-то сложный сервер. Скачай MySQL и установи. Делов на 5 минут. Настроек минимум.
592 1948715
>>1948712
>>1948713
Уже пришёл к тому, что в голове будет проще сделать. Но энивей спасибо.
image.png17 Кб, 168x546
593 1949150
Сап уважаемые
Пилю бд для онлайн магазина (пикрил схема)
Надо запилить таблицу с оформленными заказами. Как это лучше сделать? Чтоб разные заказы от одного пользователя не путались
594 1949157
>>1949150
Оставь в carts только id и user_id, создай cart_items с остальными полями и cart_id.
В categories поле is_parent, скорее всего, не нужно.
В users не нужен user_id, только id.
Ну а в таблице заказов orders ссылка на cart. И поле users либо в carts, либо в orders.
595 1949181
>>1949157
Спасибо большое, анон!

>В categories поле is_parent, скорее всего, не нужно.


это я сделал чтоб понимать, какие категории содержат подкатегории, а какие содержат товары

>В users не нужен user_id, только id.


это специфика для чат-бота
596 1949183
>>1949157
может еще в carts добавить is_ordered, чтоб понимать какую корзину отображать пользователю? (ту, которую он не оформил в заказ)
597 1949187
>>1949183
Достаточно смотреть, есть ли в orders запись с указанным cart_id, и не нужно будет обновлять carts при инсерте в orders.
598 1949191
>>1949187
по времени так не дольше будет?
599 1949193
>>1949191
Дольше, но если создать индекс, не так плохо. Да и от нагрузок зависит, вдруг некритично.
600 1949570
Суп. Используются ли в реальном мире связи между таблицами не по айдишникам? Например связывают ли cities и weather по city, который тупо строка с названием города, как вот здесь https://www.postgresql.org/docs/8.3/tutorial-fk.html? По-моему хуйня какая-то.
601 1949583
>>1949570
Иногда бывает, например когда после групбая нужно показать сразу читаемые данные, чтоб повторно не джоинить справочники. Ну это хуйня и костыли офк.
602 1949848
оракл на минт встанет нормально? стоит пытаться? для учебных целей
603 1949967
>>1949570
используют по имейлу иногда
604 1950500
Как создать функцию, которая получает два параметра и возвращает селект?
605 1950502
>>1950500
Создать процедуру вместо функции.
606 1950503
>>1950502
Зачем? ведь функция не должна ничего трогать, она только должна возвращать селект!
607 1950512
>>1950503
Семантика тут не при чём. Функция возвращает одно значение, процедура возвращает строки.
608 1950516
>>1950512
я уже понял как это делается, нормально функция возвращает таблицу
609 1950853
>>1949848
Я себе через докер все ставлю. И оракл, и sql server, и постгрес.
https://blogs.oracle.com/oraclemagazine/deliver-oracle-database-18c-express-edition-in-containers
610 1950856
>>1950516
Покожи как?
И в кокой субд?
image.png13 Кб, 502x239
611 1950924
Увожаемые, сможете найти ошибку в синтаксисе?

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 ')'.
Ебусь несколько часов. Видимо, я слепой нахуй.
612 1951017
>>1950924
У тебя открывающих скобок 10, закрывающих 12.
Понаберут по обьевбляние дибилов блядь, которые уже даже в спизженном коде скобки не могут проставить.

Любое IDE может показывать пару скобоку, ты что совсем долбаёб?
613 1951120
>>1951017
Не знаю, ты реально тупой или так толсто меня пытаешься троллить?
image.png57 Кб, 866x687
614 1951133
>>1950856
рофшиль? загуглить не судьба?
images.jpg5 Кб, 226x223
615 1951155
>>1951120
Ты скобку не можешь в нужном месте поставить, а тупой я.
616 1951238
>>1951155
Всё правильно, тупой ты

>У тебя открывающих скобок 10, закрывающих 12

image.png28 Кб, 734x485
617 1951572
Доброго времени суток аноны. Помогите пожалуйста решить одну задачу новичку. Пикрил схема
Как лучше всего получать order, имея user_id? Можно как-то сделать это одним запросом? Или нужно джойнить carts и orders?
618 1951660
>>1951572
если кто знает, как это сделать в Gino, скажите пж
619 1951666
Ну и как мне сделать джойн между двумя индексами в эластике?
620 1951872
>>1951660
select c.id,c.user_id,c.ordered,o.id
from carst as c inner join orders as o
on c.id=o.cart_id
where c.user_id=ID
PxTmK1QO3NM.jpg99 Кб, 900x900
621 1951876
Котаны пилите перекат, совсем тонем. Тому кто перекатить помогу решить лабу или что там решаете на скуле
16141479152070.png400 Кб, 600x436
622 1952379
Есть один sqlite дб файл в локалке и есть 2 программы которые к нему подключатся. Если они начинают делать почти синхронно запросы на запись то обе фризятся до условного таймаута. Это можно как-то пофиксить?
inb4:

>ставь sql сервер


Мне нужно чтобы этот дб файл юзверь мог условно скачать и работать с моим приложением без йоба инструкций с поднятием sql сервера. И да, в то же время мне нужно чтобы с бд файлом могли работать множество пользователей. Пока что думаю вынести логику в общий файл в ридонли, а то что идет на запись - создавать локальную бд. Благо что-то записывать в общую бд нужды пока что нету.
623 1953006
Cап, двач. Нужно писать в бд много и параллельно, ждать результата не нужно. Есть какие-то очереди реквестов на инсерт, типа отправил - забыл, чтобы СУБД сама очередь делала и писала по возможности? Или что-то другое использовать для очереди, тогда что именно?
624 1953111
>>1953006
Kafka + коннектор к твоей субд.
625 1953124
к какой колонке таблицы users(id, email,login) лучше привязать внешнюю таблицу order(товар,номер,сумма,дата)?
626 1953127
>>1953124
Все привязки лучше делать через id.
627 1953136
>>1953127
еще вопрос,допустим у меня слишком много юзеров.
я захожу в панель управления и и хочу видеть только активные заказы в этой куче мале?
в таблице юзер делать колонку со статусом(в процессе или доставлено) а потом просто в хтмл делать сортировку этой колонки(наверху доп в процессе)?
628 1953145
>>1953136
Статус нужно делать в orders, если сделать в users, один пользователь не сможет сделать за раз больше одного заказа. Да и костыльно как-то.
Сделай джойн users и orders по users.id = orders.user_id и добавь индекс для orders на колонки user_id и status.
629 1953208
как записать в БД набор цифр (с пробелами) типа 12 26 66 9?
630 1953270
>>1953208
как текст?
631 1953316
>>1953208
Когда надо несколько значений можно выбрать один из вариантов:
1. Сделать на каждую цифру колонку. Но тогда таблица может быстро вырасти
2. Записать как строку. Но понятно, что по одной какой-то цифре искать нельзя будет нормально. (можно, но это пиздец)
3. Кодировать бинарно числа в одно.
В общем зависит от контекста задачи.
632 1953327
>>1953316
это типа комбинации(9 штук),которые потом надо будет сверять
Снимок экрана 2021-02-27 211408.jpg42 Кб, 988x257
633 1953376
В чем причина?
634 1953406
>>1953327
Ну если у них одна и та же последовательность и ты по ним потом джойнить ничего не будешь, то пихни в строку
изображение.png5 Кб, 313x161
635 1953586
>>1953208
Вместо пробелов запиши тире, будет как UID.
Либо в каком-нибудь xml храни.
Либо просто текстом с пробелами.

заебали, пилите перекат уже
636 1953678
>>1953376
>>1951572
Какие же двачеры идиоты, просто пиздец.
637 1953714
>>1953678
по делу что скажешь?
638 1953725
>>1953714
По делу - тебе не стоит заниматься программированием, если ты не можешь найти ответы на такие вопросы самостоятельно.
639 1953734
>>1953725
Уёбок, что ты забыл в /pr/?
640 1953816
>>1953734
Забыл тебе в рот нассать, открывай.
641 1953821
>>1953816
Мамке твоей открыл.
642 1954139
Сап /b /pr, скорее всего скоро придется завалиться на проект, где будет дохуя низкоуровневой ебли с базами данных (прям хардкор, писать оптимизаторы sql запросов, патчить PostgreSQL и всякие такие штуки), но проблема в том, что я нихуя не знаю как работают, и как они устроены внутри (буквально на выходных прочел и написал Btree), даже сам SQL хуево знаю. Собсна вопрос - есть ли какие-то книги, которые описывают как бд работают изнутри? (желательно с кодом и не особо старые).

Обнял <3
643 1954152
>>1954139
Если хочешь выучить ANSI sql на мастер лвл - иди на sql-exe
Если тебе интересны кишки постгри - начни с этого курса:
https://postgrespro.ru/education/courses/DBA1
Дальше по иди по их роадмапу.
644 1955474
Народ, а можно ли взаимодействовать с Postgres, не держа с ней постоянных соединений, а, скажем, с каждым запросом слать некий token, который бы содержал инфу об авторизации? Чё-то не гуглится пока ничего на эту тему.
645 1955496
>>1955474
Какую проблему ты хочешь решить этим способом?
646 1955547
>>1955496
Хочу написать лямбды (Next.js), которые будут слать запросы к Postgres. Проблема в том, что одновременно выполняемых лямбд (и, как следствие, соединений с базой) может быть много. Ну и создавать каждый раз в лямбде клиента для Postgres (и ждать, пока установится соединение) только чтобы отослать через него 1 или несколько запросов - это нехорошо.
Можно, конечно, написать и работать через отдельную прослойку, которая будет держать постоянные соединения с Postgres, с авторизацией по токенам, но я думал, может, Postgres уже сама что-то такое умеет.
647 1955637
>>1955547
То, что ты ищешь, называется connection pooling, и оно есть в большинстве клиентов субд.
648 1955769
>>1955637
Кроме говна написанного на жсе
649 1955917
Существуют ли какие-нибудь семантические подходы, которые позволяют писать 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
649 1955917
Существуют ли какие-нибудь семантические подходы, которые позволяют писать 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
650 1955942
>>1955637
Ты не понял. Лямбда - это новый процесс, который создаётсся для обработки каждого нового запроса (я же о serverless архитектуре говорю). И, если действовать по-старому, то для доступа к бд в каждом таком процессе нужно создавать новое соединение, которое закрывается при завершении процесса после обработки запроса. Лямбды могут запускаться на разных компах. И никакого connection pooling тут быть не может.

Что касается жс-а, то в клиенте pg этот connection pooling был изначально (с 2010 года, по-моему). Но это к слову.
651 1955962
>>1955942
Тогда, из вариантов:
Pg_bouncer как минимум.
Создавать объекты соединений с бд вне хендлера и надеяться, что процесс будет переиспользован
Таки ставить прослойку в виде odata/graphql (например https://www.moesif.com/blog/graphql/technical/Ways-To-Add-GraphQL-To-Your-Postgres-Database-Comparing-Hasura-Prisma-and-Others/) и ходить в бд через неё.

Вообще да, облачные функции плохо дружат с субд, где надо поддерживать постоянные соединения. В oracle cloud дают халявные 2 бд с 20гб, и на каждую всего 20 соединений - новое создается около 30 секунд, и они быстро исчерпываются. Т.е. лучше вообще использовать какое-нибудь nosql с нативным http api.
652 1957369
Тупые долбоебы, что вам мешало нумеровать треды? Стоя на ёбаной развилке полчаса пытался понять в какой идти по их описанию, а оказывается это одна ветка. Свиньи блять.
653 1957457
Хелп, двач. Дано: таблица 1, где лежат 5-10 строки основной таблицы и 4 левых строки, таблица 2, где лежат 1-20 строки основной таблицы, и запрос

merge таблица1
using таблица2
on (таблица1.ключи = таблица2.ключи)
when not matched then insert {таблица1.поля) values (таблица2.поля)

Вопрос - какого хуя запрос игнорит 1-5 строки второй таблицы и вставляет только последние 10? Я тупой, да.
изображение.png42 Кб, 170x170
654 1957896
>>1957457
Я знаю в чем дело, но расскажу после переката
655 1958478
Анон, почему ты до сих пор не даталог?

https://www.youtube.com/watch?v=oo-7mN9WXTw
https://gist.github.com/pithyless/e00362aa6061bfb4e4749079a33be073

Алсо, какого хуя вы не перекатываете и не можете пронумеровать треды, пиздец просто, все у вас как всегда через жопу.
656 1959014
>>1957896
А там всё и правильно было. Неплохая попытка перекатить тред.
457457457.jpg82 Кб, 800x600
657 1959817
Кто умеет в Microsoft SQL Server Management Studio?
Задали диаграммы сделать но таблицы для них не отображаются. Я создал базу данных, создал таблицы, добавил данные. Что делать дальше я не понял. Вроде begin transaction; commit transaction; но что это по факту делает я не разобрался.
658 1960353
>>1959817

>Задали диаграммы сделать


Иди нахуй, школьник.
Untitled.png89 Кб, 1360x599
659 1960443
в чем я не прав?
660 1960452
когда JSON оправдан?
661 1960453
>>1960443
мда, походу в сикулайте нет этого "all", а в курсе сука есть
662 1961727
Народ, какое количество строк максимально база способна переваривать, 10м строк это много для базы? Какая по параметрам должна быть база, что бы сожрать 10 Милионов строк и выдавать их не давясь?
663 1964574
Заебали право слово, перекат >>1964573 (OP)
664 1992935
Изучаю sql, возникла проблемка с таким типом задачи: есть 3 таблицы (работники, пк, работник_пк). В "работниках" поля id, имя, фамилия. В "пк" id и производитель. В связующей id, id_работника и id_пк. Связь многие ко многим.
Задача вывести имена работников за которыми привязано больше 2 пк. К сожалению идей нет как делать это задачу. Понимаю, что надо как-то через джоины, но дальше хз
665 2004735
>>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

мб так можно? таблица пк даже не понадобится по идее, так как там только данные о производителе содержатся
пишу с телефона и не могу прогнать запрос, но по идее может сработать)
Тред утонул или удален.
Это копия, сохраненная 10 мая 2021 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /pr/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски