>>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 к записей в год при нормальном проектировании любая реляционка выдержит как нефиг делать (советую постгрес). И будет во много раз быстрее тормознутой монги.

>>1887079

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

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

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

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

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

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

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

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

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

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

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

>>1887062

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

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

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

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

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

Помогите плз задачку решить с sql-ex.
Select(обучающий этап). Задача 125. Решаю на MS SQL Server

ЗАДАЧА
Данные о продаваемых моделях и ценах (из таблиц Laptop, PC и Printer) объединить в одну таблицу LPP и создать в ней порядковую нумерацию (id) без пропусков и дубликатов.
Считать, что модели внутри каждой из трёх таблиц упорядочены по возрастанию поля code. Единую нумерацию записей LPP сделать по следующему правилу: сначала идут первые модели из таблиц (Laptop, PC и Printer), потом последние модели, далее - вторые модели из таблиц, предпоследние и т.д.
При исчерпании моделей определенного типа, нумеровать только оставшиеся модели других типов.
Вывести: id, type, model и price. Тип модели type является строкой 'Laptop', 'PC' или 'Printer'.

МОЙ ЗАПРОС

with LPP as (select 'PC' as type, code, model, price
from PC
UNION ALL
select 'Laptop', code, model, price
from Laptop
UNION ALL
select 'Printer', code, model, price
from Printer), AA as (select row_number() over(order by code desc, type) down_sort,
row_number() over(order by code, type) up_sort, code, type, model, price
from LPP)

select down_sort, up_sort, type, model, price
from AA

Я короче сделал сортировку первый-второй-третий (up_sort) и последний-предпоследний (down_sort)
Но вот как сделать их чередование я хз. Так что либо помогите допилить мое решение, либо тупо скиньте свое, в любом случае поклон вам в ноги

>>1887288

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>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-секторы.
Значит надо два файла, походу, и репликацию заебенить. И ремап. Тупая, короче, идея.

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

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

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

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

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

>>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

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

>>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

>>1891143

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>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, должны добавиться записи дополнительные,
чтобы там появились новые значения, которые может вводить только сам админ базы данных этого вот Пентогона.
И главное, чтобы без пердолинга!! А то я уже заибался с этими таблицами.
Я ЩА ВОЛОСЫ НА ЖОПЕ СИБЕ ПАРВУ, ПАМААААААГИТИ!!!

>>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 замыкаются,
и оно ошибки бьёт.

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

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

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

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

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

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

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

нет, нет, тут не совсем так ты меня понял. Я пытался выбрать именно оптимальную структуру БД, и понять как строить - на базе неё любые модели данных.
Хотя, впрочем, я описал уже выше, в этом посте, как, к этому, я подошёл.