>>1974967

>твоему MVC уже пiзда

В контроллере вызов метода из репозитория:
$paginator = $this->indexRepository->getWithPaginate(9, $selectedCategory, $currentExchangeRate, $cartId);

В репозитории indexRepository проверяем, выбрал пользователь категорию товаров или нет. Ну и обращаемся к модели, подставив в неё SQL-команду для перевода прайса в нужную валюту прямо при запросе. Я не знаю, это считается, что я работаю с базой из контроллера, или всё же нет?
public function getWithPaginate($perPage, $selected, $exchangeRate, $cartId)
{
#If a category is specified and it is NOT root, then the category is checked
if ($selected <= 1) {
$checkType = '<>';
$selected = 0;
} else {
$checkType = '=';
}

#Get data
$results = $this
->startConditions()
->select('id', 'title', 'slug', 'category_id', 'description', 'image_url',
\DB::raw("ROUND((price::numeric / $exchangeRate),2) AS price"))
->where('is_published', 1)
->where('category_id', $checkType, $selected)
->orderBy('id', 'ASC')
->with([
'category:id,title',//we will refer to the category relation
'cartItem' => function ($query) use ($cartId) {
$query->where('cart_id', $cartId)->select(['product_id', 'quantity']);
}
])
->paginate($perPage);

return $results;
}
Сама модель:
namespace App\Models;
use Illuminate\Database\Eloquent\SoftDeletes;
class Product extends BaseModel
{
use SoftDeletes;

protected $fillable = [
'title',
'slug',
'category_id',
'description',
'price',
'image_url',
'is_published'
];

public function category()
{
return $this->belongsTo(Category::class);
}

public function cartItem()
{
return $this->hasOne(CartItem::class);
}
}

Есть таблица
atr_1
1
2
3
4
5
Я её могу проранжировать
atr_1
1 1
2 2
3 3
4 4
5 5

Я могу это сделать роу_намбером

А если я хочу проранжировать её вот так
1 5
2 5
3 5
4 5
5 5
6 10
7 10
8 10
9 10
10 10
11 15
12 15
И тд. есть для этого какая-то надстройка или костыль нужно изобретать?

>>2020054

> нужна целая, пиздатая СУБД, которая не всегда может поставится

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

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

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

> лицензии могут быть несвободные, и всякое такое.

А могут быть свободные. Ты наугад выбираешь СУБД что ли, или всё-таки ищешь подходящую под задачи с подходящей лицензией?

> возможно ли работать с базой данных, БЕЗ СУБД?

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

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

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

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

Примитивная СУБД так и будет работать.

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

Именно так, поэтому этого не делают.

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

Гугли 12 правил Кодда, это минимальные требования к релцяционной СУБД. Написать с нуля, конечно, возможно всё, но легко сдаться на первых сложностях наподобие реализации ACID-транзакций.

Короче, бери sqlite.

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

У меня, здесь, короче, Windows XP, CSharp (C#), и .NET Framework 4.0. И ещё есть mono на ubuntu,
где можно запускать шарповый код, совместимый с .NET Framework 4.0.

Единственную норм приложуху для тыканья sqlite3 DB, что я нашёл -
так это мокрописька Sqlite Expert Professional 5.3 (x86), с кряком от васяна.
Да, там есть гуй, и куча всяких свистоперделок, но сореца нету нихуя.

Я вижу, что она использует sqlite3.dll , потому что она есть там, внутри, прекомпиленная.
А где её сорец и как её сбилдить, и как юзать - вообще непонятно нихуя.

Нашёл здесь: https://github.com/moneymanagerex/System.Data.SQLite
сорец System.Data.SQLite.dll вроде оно компилится на c# ,
и на выходе в папке System.Data.SQLite-master\bin\2010\Win32\Debug\System.Data.SQLite.dll
лежит многовесный файл 2,80 МБ.
Он, походу, содержит в себе System.Data.SQLite.Interop.dll, который просят всякие гуи,
и работает как sqlite3.dll
Другой файл \System.Data.SQLite-master\bin\2010\Debug\bin\System.Data.SQLite.dll
имеет меньший размер, и когда его кидаешь, просит SQLite.Interop.dll (а я ебу что это такое ваще).
Ещё, в папке \System.Data.SQLite-master\bin\2010\Debug\bin\ куча всяких других, непонятных dll-лок,
я уже заебался гуглить всю эту хуйню и закрывать вкладки, эти ебучие, а потом опять открывать, и закрывать, блядь.
Искал я как работать с этой хуйнёй на шарпе, наткнулся на это: https://devpractice.ru/sqlite-c/
И там, внутри, какие-то конструкции из кода нагороженные, нихуя не понятно что к чему.
Затем я искал нормальное API, и наткнулся на вот такую софтину: https://github.com/donet5/SqliteSugar
хоть она и компилится, но там многобукв в коде, ещё и по-китайски.

Хотелось, бы, блядь, одну dll-ку, из кода скомпилить, приложить её, и дёргать за апи-методы, и пхать туда sql-запросы,
а не писать в говнокоде ебические конструкции, каждый раз подключаться, блядь, к файлу базы, для каждой операции,
и развозить всю эту хуйню - на 10,000 строк.
Судя по сайту https://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki
там есть справка в формате CHM, как его открыть - вообще не ебу, у меня открывается окно, а там такое говно.
Короче, блядь, как заебал уже весь этот пердолинг ебучий,
да и нахуй мне все эти функции и свистоперделки сиквелайта?

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

>>2020674

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

А я бы напротив сделал софтины обратно-совместимыми даже с таким вот сервером, чтобы они были вообще пиздец какими кроссплатформенными.

>А ещё они могут быть в процессоре, в ОС, в компиляторах, в мозгу с рождения, в прививке от коронавируса.

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

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

>А могут быть свободные. Ты наугад выбираешь СУБД что ли, или всё-таки ищешь подходящую под задачи с подходящей лицензией?

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

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

ВОТ. Есть где-то вводная инфа, о том, как это можно сделать?

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

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

>Примитивная СУБД так и будет работать.

Вот именно это и вертелось, и вертится на уме. Сделать примитивную СУБД, которая тупо работала бы с одним бинарным файлом.
И что если писать прямо в конкретные смещения, на диске, не перезаписывая весь файл?
Быть может я и пытаюсь изобрести сиквелайт, лол. Просто я в него так и не врубился, толком.

>Именно так, поэтому этого не делают.

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

>Гугли 12 правил Кодда, это минимальные требования к реляционной СУБД.

Годно, но них ещё врубиться надо, по хардкору, чтобы понять их.

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

Ну это вообще космос. А нафиг они нужны?

>Короче, бери sqlite.

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

>>2021264
Тут есть NoSQL базы данных, то есть, как-бы нереляционные.
А мне надо реляционная, потому что там можно взаимосвязывать таблицы.
И мне нахуй не нужны ебические СУБД со всякими проприетарными лицензиями, которые просят бабала, и ставятся прямо в систему из инсталлера,
или запускаются на сервере где-то, где могут спиздить данные, блядь.
В идеале, я бы хотел простую и легковесную СУБД, желательно свою, и чтобы она была портабельной на флешке, как сиквелайт,
и чтобы, тупо чтобы вязать всякую хуйню, наподобии пикрил.
Вот надо расписание, например, сделать тупо. Две таблички взаимосвязать, как на пик2.
Так что для этого целый постгресс вытягивать и инталлер распаковывать?
Или сервер поднимать с проприетарным мускулом, состоящим из прекомпиленных файлов, блядь,
и писать скрипты на PHP, и делать целый сайт и ещё и хостить его, блядь?

>>2021600

> Там всё копирастическим и корпоратокративным языком написано, чтобы запутать анона, и чтобы он забил на это хуй поскорей.

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

> Единственную норм приложуху для тыканья sqlite3 DB, что я нашёл -

> так это мокрописька Sqlite Expert Professional 5.3 (x86), с кряком от васяна.

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

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

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

> Но так, чтобы было опенсорец вообще заебатый.

Так и напишешь свои 100500 строк, будет ничем не лучше существующего.

> А я бы напротив сделал софтины обратно-совместимыми даже с таким вот сервером, чтобы они были вообще пиздец какими кроссплатформенными.

Если заниматься поддержкой всех некро-платформ с 3.5 пользователей, времени на разработку самой СУБД не будет вообще.

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

Зачем, если все исходники postgresql, mariadb и sqlite полностью доступны. То что сложно и многабукаф - это другой вопрос.

> Я хочу самую свободную и реляционную СУБД

postgresql, mariadb, sqlite.

> ВОТ. Есть где-то вводная инфа, о том, как это можно сделать?

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

> А если в архиве их хранить, чтоб дохуя места не занимали - это раз.

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

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

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

> Вот именно это и вертелось, и вертится на уме. Сделать примитивную СУБД, которая тупо работала бы с одним бинарным файлом. И что если писать прямо в конкретные смещения, на диске, не перезаписывая весь файл?

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

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

Экспоненциальный рост числа этих нуллов быстро сожрёт всё свободное место на диске. Если у тебя есть 10 таблиц, в каждой по 10 колонок и по 100 записей (сравнительноая небольшая БД), но при превращении в одну огромную таблицу это будет (10x100)^10 = 1000000000000000000000000000000 ячеек, каждая в лучшем случае будет занимать один байт.

> А на sqlite существуют какие-нибудь сайты на шарпе?

> Вот, например, какой-нибудь сайт с личным кабинетом, интернет-аукцион, скажем,

> где юзер может зарегистрироваться и зайти в аккаунт?

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