Для чего вы вообще создаете пет-проект? Есть вариант - чтобы пройти собеседование.
В этом случае включайте туда все что будет интересовать работодателя.
Читал, что при использовании JOIN индексирование бесполезно.
Вот интересно где ты это читал. Я конечно знаю что мы живем в эпоху "плоской земли". Это когда любой заблуждающийся может найти целое сообщество таких-же заблудших душ. Ну да ладно.
Поскольку разработка под БД и SQL - это практика. То ты можешь подойти с практической стороны. Взять 2 таблицы (желательно поболее 1 гигабафт) и сделатьй JOIN их по PK и ссылочному ключу без индекса. И потом тоже самое с индексом. И не забудь предложение WHERE потому что оно тоже имеет значение.
Вообще индекс в наше время - это trade-off. Сделка по сути. Мы платим налог в виде какого-то % IOPS/CPU во время вставки OLTP транзакций и мы это ПРИНИМАЕМ и соглассны с этим.
Но мы взамен имеем очень короткое время поиска данных или JOIN.
Вообще проверь это все. И не верь никаким писателям.
И мне тоже не верь. Проверяй на своей базе время выборки для всего SELECT.
AHMED_RAPIRA, Rust - это сложный компиллятор. По крайней мере у него есть промежуточный слой LLVM кодогенерации. На этом слое скорее всего будет явно использован тип i8. А после сборки в целевую платформу (x86_64) скорее всего информация об 8 разрядном регистре может быть потеряна и может всплыть регистр AL/AX/EAX как регистр для алгебраических типов и для целых расчетов в принципе.
Попробуй
cargo rustc -- --emit=llvm-ir
и посмотри промежуточный код в текстовом виде.
И потом любым дизассемблером посмотри свой бинарник.
Почему С-разработчики не умеют пользоваться модульными тестами?
Вот ни разу не видел. Java/C# - умеют. Сишники - надеются либо на мануальное тестирование либо просто на ручной коде-ревью. Это не выпад в адрес языка С.
AHMED_RAPIRA, я не буду спорить. Я просто говорю свое предположение на основании наблюдения за ассемблерным кодом. Если у вас есть контр-пример - пожалуйста приведите.
Flesh Herbal, я с вашего позволения не хочу смотреть. Я просто примерно предположу что если у вас нет consistency - то можете просто использовать файловую систему. Это хороший старт. Нулевые накладные. Никакой лишний процесс не создается. PrimaryKey == имя файла. И все write only и работает хорошо. До тех пор пока вы не озвучите дополнительные требования по поиску и индексированию. А поскольку вы не озвучили то вам подходит даже файловая система.
Мне кажется что все современные переводчики - это сервисы. Поэтому вопрос про java - является как-бы ненужным уточнением. Есть rest-сервис - бери пользуйся хоть с Java хоть с Python.
А делать специальное приложение на java смысла нет. Язык сильно быстро эволюционирует. Появляются новые молодежные слова. И любой хардкод справочников слов устаревает очень быстро.
Непонятно какой смысл автор вкладывает в "локально". Ну поставь себе любую dbms на локальный хост - вот и будет локально. И PostgresSQL и MySQL можно поставить.
Если брать какие-то узко-специализированные типа БД на файлах или embed, то там SQL будет ограниченным. Не будете развивать приложение в смысле SQL.
А зачем это вам надо? Хотите быть неразвитым и отсталым?
Есть анекдот про двух алкашей и огурчик. Который был "измучен" до того как пойман в банке.
Вот мне кажется что автор решил "измучать" хабр задавая много раз один и тот-же вопрос.
Из недостатков. Всё бесплатное - без техподдержки. Если у тебя какой-то ORA-600 или бох его знает какая ошибка - то тебе некуда будет с этим пойти в облаке. Максимум что тебе предложат - это оплатить подписку.
Да бери Google BigTable и изучай возможности. Для студентов и учащихся обычно Амазон и МС и Гугл дают шанс поиграться 1-2 месяца безплатно. Потом все равно надо платить. Но есть еще всякие скидки и акции на обучение.
Я впервые слышу чтобы математическая логика делилась по политическим жанрам. Очень хотелось бы услышать какой-то пример. Убежден пока что лучшие учебники по физике и математике написаны в 20м веке.
Насчет истории-политологии там как-бы всё ясно. Есть загибы...
