Программирование

Ответить в тред Ответить в тред
Check this out!
Шардинговый реплицируемый баз данных тред. Шапка Edition v1.0 /sql/ Аноним # OP 30/11/20 Пнд 22:34:51 18696161
image.jpg 798Кб, 1941x2560
1941x2560
image.png 274Кб, 429x420
429x420
Новый баз данных тред, теперь с альфа-версией шапки.

Здесь мы:
- Негодуем, почему шапка - говно, и предлагаем коллективному ОПу идеи, как её улучшить.
- Разбираемся, почему 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)
Аноним 30/11/20 Пнд 23:07:09 18696282
screenshot-2020[...].png 65Кб, 1335x434
1335x434
Уже больше двух лет пытаюсь начать задания на sql-ex.ru
Каждый раз когда перехожу по ссылке даже если ссылка работала у человека чье задание пытаюсь разобрать у меня показывает пикрил
Что я делаю не так?
Аноним 30/11/20 Пнд 23:15:22 18696313
>>1869628
www и без это разные домены. Скоре всего дело в этом.
SAGE Аноним 01/12/20 Втр 00:03:44 18696444
Шапка говно, книги говно. Объявляю тред нелегетимным. Сажи перекатчику дебилу.
sage Аноним 01/12/20 Втр 00:04:00 18696455
sage Аноним 01/12/20 Втр 00:04:22 18696476
sage
sage Аноним 01/12/20 Втр 00:05:39 18696507
sage
sage Аноним 01/12/20 Втр 00:07:22 18696528
изображение.png 12Кб, 698x420
698x420
Аноним 01/12/20 Втр 00:13:39 18696589
image.jpg 27Кб, 512x548
512x548
Хз норм помоему
Сделайте тред в любом случае по бд пожалуйста нужно срочно вкатиться в пж буду срать
Аноним 01/12/20 Втр 00:15:53 186966010
>>1869658
В анус себе вкатись, псина, область и так уже полудохлая.
Аноним 01/12/20 Втр 00:19:15 186966311
Аноним 01/12/20 Втр 00:19:41 186966412
>>1869663
Почти вся, что связана с БД.
Аноним 01/12/20 Втр 00:33:37 186967513
image.jpg 28Кб, 640x480
640x480
Аноним 01/12/20 Втр 00:34:11 186967614
Аноним 01/12/20 Втр 00:35:44 186967915
>>1869676
У тебя за щекой, проверяй.
Аноним 01/12/20 Втр 00:41:05 186968316
>>1869676
У тебя куда-то весь веб пропасть успел?
В смысле область бд полудохлая?
Аноним 01/12/20 Втр 00:45:52 186968817
Ради интереса глянул, на HH куча чистых вакансий Oracle PL/SQL и MS SQL.

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

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

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

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

Что из бесплатных DBMS выбрать под такие нужды?
Аноним 01/12/20 Втр 09:39:27 186979820
изображение.png 34Кб, 285x177
285x177
Аноны помогите разобраться с merge.

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

Таблица

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

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

Код
https://pastebin.com/2XSAQLeq
Аноним 01/12/20 Втр 19:59:07 187035821
2020-03-08 13.2[...].jpg 133Кб, 1080x1080
1080x1080
Внимание! Срочно поделитесь опытом использования dynamo db!
Аноним 01/12/20 Втр 20:11:58 187036522
>>1870358
Кей-валуе специфик носкуль же, какой опыт может быть?
Аноним 02/12/20 Срд 01:34:19 187057223
>>1870365
>Кей-валуе
Очевидно ты туда даже не заглядывал. Это тебе не редис. Есть особенности моделирования реляционных данных, выбора праймари и сортинг ключей, аксесс паттернов, учёт ограничений на дёрганье партишенов. Динамо безусловно лучшее масштабируемое решение на рынке
Аноним 02/12/20 Срд 01:46:45 187057724
Аноним 02/12/20 Срд 01:55:35 187057825
>>1869752
>нубу
postgresql

там есть всё что тебе нужно искаропки если сумеешь создать пользователя :cf:
Аноним 02/12/20 Срд 05:31:01 187061026
>>1869616 (OP)
>Q: Что лучше, SQL или NoSQL?
>A: Как обычно, зависит от задач. Нужна любой ценой скорость - бери NoSQL, нужна согласованность данных - SQL.


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

зато хипстеры будут в губы целовать
Аноним 02/12/20 Срд 07:08:07 187062827
Кстати чем из nosql визуализируют данные обычно?
Аноним 02/12/20 Срд 10:44:29 187068328
>>1870610
> если тебе нужны ебанутые бредовые результаты,
> но быстро,
> то бери NoSQL
Всё же можно придумать несколько юзкейсов, когда частичная или полная потеря данных некритична. Какой-нибудь кеш на редисе, который будет in-memory, собирается заново при перезапуске сервера. Что-нибудь по-быстрому посчитать в какой-нибудь бигдате, используя БД как промежуточное хранилище расчётов без дальнейшего хранения. По-быстрому высрать продукт с коротким временем жизни и не требующим поддержки - это как языки с динамической типизацией, где можно по-быстрому получить хоть и хуёвый и нестабильный, но результат.
Аноним 02/12/20 Срд 10:52:26 187068529
Аноним 03/12/20 Чтв 02:35:26 187149830
>>1870683

например результаты голосования
Аноним 03/12/20 Чтв 12:22:22 187163531
>>1870610
Ну для какой-нибудь синхронизации тудушки на нескольких мобилках самое то
Когда у тебя один таск может расшариться с одного девайса на 2 других, на втором модифицироваться и на третьем удалиться будучи неподключенным к интернетам ты на склах адекватно это не реализуешь в принципе
Аноним 03/12/20 Чтв 13:28:11 187167632
>>1871635
Данные активной сессии можно хранить там, что бы в базу не лазить
Аноним 03/12/20 Чтв 15:49:54 187182033
Относительно недавно работаю в финтех области(больше уклоном в фин), думал подучить в свободное время sql, но глянул вакансии по ключевому слову sql - требуются одни программисты. Стоит ли вообще заморачиваться этим не прогерам?
Аноним 03/12/20 Чтв 15:59:42 187182734
>>1869616 (OP)
Читал эту мангу, по базам не очень, математические поинтереснее.
>>1869688
Нет, это грязное SQL-программирование на процедурных языках с элементами ООП, требующее знания возможностей базы далеко за пределами CRUD.

В частности pl/sql - это часто программирование ETL-операций на диалекте паскаля, реже написание хранимок скрывающих сложную структуру данных.
Аноним 03/12/20 Чтв 16:14:09 187183735
>>1871820
разумнее прокачиваться в тех направлениях, которые тебе в проф. деятельности помогут, разве нет?

если тебе не нужен скл, то и фиг с ним
Аноним 04/12/20 Птн 14:21:12 187269736
myisamtoinnodbf[...].jpg 28Кб, 817x575
817x575
Перевел в mysql myisam в innodb. Ну ахуеть теперь!
Может стоило остаться ?
или попробовать вместо utf8mb4 utf8bin ?

Ну и запросы немного разъехались тоже.
Аноним 04/12/20 Птн 14:33:50 187270837
>>1870610
>ебанутые бредовые результаты
Eventual consistency, которая, как правило, имеет место у NoSQL DBMS, на 100% подходит для записи всего, что происходит один раз: история изменений цен на акции/курсы валют, история финансовых операций, история поведения пользователя и т.п.. Т. е. применений у NoSQL не так уж и мало.
Потом конкретно у DynamoDB есть возможность делать strongly consistent reads - операции чтения, гарантированно возвращающие последнее значение полей записи в рамках одной зоны. В зонах, как правило, несколько локаций, и неважно, из какой локации писали в базу/читают из базы.
Аноним 04/12/20 Птн 20:02:31 187310038
какие есть места куда берут только с sql?
Аноним 04/12/20 Птн 20:54:42 187313539
>>1873100
Профессия так и называется SQL Engineer
Но очевидно по своей узкой специализации на джуна нужны знания на уровне знаний лоу сениора веб-макакена
Аноним 05/12/20 Суб 04:03:59 187329440
Аноним 05/12/20 Суб 06:41:17 187331141
Поясните за оптимизацию 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сек


Аноним 05/12/20 Суб 20:00:24 187372242
>>1873311
а хуй его знает, почитай про 'Partial Index', сверху можно докинуть индекс на контролькую сумму строки (чтобы не по строкам индексировать/искать) и/или через any в массивах изъебнуться.
Аноним 05/12/20 Суб 20:11:59 187373343
>>1873311
Порой сильно мешает эта хуйня, что порядок вычисления частей AND и OR в оракле не гарантирован, как в обычных языках программирования. Несколько раз проёбывался из-за того, что в правой части AND вызывается функция, которая кидает исключение, когда проверка в левой части даёт False, и если бы порядок гарантировался, исключение не кинулось бы никогда. Приходится из-за этого городить костыли с CASE WHEN.
Аноним 07/12/20 Пнд 06:10:33 187476144
Поясните, в чём отличие процедуры от функция, кроме того что функция не умеет INSERT/UPDATE, но может использоваться SELECT. В каких случаях нужно использовать первой, в каких второе офк кроме очевидных ситуаций которое попадают под ограничения?
Аноним 07/12/20 Пнд 11:21:23 187486245
>>1870610
Еще не рекомендую автомобили. Да быстро. Но можно умереть. И кто то даже умрет. Оно того не стоит. Ногами лучше.
07/12/20 Пнд 12:17:50 187488746
Аноним 07/12/20 Пнд 12:33:20 187489247
>>1874862
Да, автобляди соснули
Аноним 07/12/20 Пнд 20:53:59 187520148
А работал кто с MySql через MATLAB?
И может кто подскажет: как я понимаю реляционная база данных-это большая такая таблица, которая имеет связи с другими таблицами. И есть ли какие-то конструкторы БД? Чтобы как-то графически сделать макет базы данных, а потом уже начать ее кодить/заполнять? Просто сейчас у меня на ум приходит сделать только две таблицы, но со временем БД надо будет расширять.
И что лучше MySQL или MS SQL?
Аноним 07/12/20 Пнд 21:00:19 187520849
>>1875201
>как я понимаю реляционная база данных-это большая такая таблица
Нет
>И есть ли какие-то конструкторы БД?
Какие-то гушные инструменты были, что то подобие конструктора
>И что лучше MySQL или MS SQL?
Если у тебя ничего сложного не будет, то бери что знаешь. Если будет - советую посмотреть в сторону постргреса
Аноним 07/12/20 Пнд 21:20:05 187523250
>>1875201
Хосспаде, выгрузи csv и поработай в матлабе. Обязательно оперативность из матлаба нужна?
Аноним 07/12/20 Пнд 23:07:15 187535351
А какой нынче бекап mysql не мудацкий?
Есть ли наиболее полный и популярный скрипт?
и желательно чтобы без qpress.

мне нужны инкрементальные и полные бекапы, но не хочу опять на шелле постоянно все городить. я устал :(
Аноним 07/12/20 Пнд 23:35:13 187537152
>>1869616 (OP)
Хосспаде. Неужели шапку сделали! Наканец-та пора учить SQL. На работу сука не берут без него.
Аноним 08/12/20 Втр 20:53:34 187610953
Анон, без sql не берут на работу.
Можешь плез посоветовать самый быстрый способ набить такой минимум с которым не стыдно будет проходить собеседования?
Аноним 08/12/20 Втр 21:03:35 187611454
>>1875371
>>1876109
куда вы все устраиваетесь, что везде нужен скл?
Аноним 08/12/20 Втр 21:08:28 187611755
>>1876114
Да это оба моих сообщения. Забыл что вчера примерно тоже писал.
Ну вообще везде, где есть бэкенд. Пишу на пщ и петухоне. На каждом собесе спрашивают про sql. А я то хули, когда писал на питоне пользовался орм, а когда на го - были свои БДшеры.

Так и не выучил. Хуй получается работу поменять.
Аноним 08/12/20 Втр 21:29:59 187613256
>>1876109
Если идёшь на простого разраба, а не БДшника, то там и учить-то почти нечего, за пару недель можно управиться.
Берёшь какой-нибудь хуёвый гайд ( https://metanit.com/sql ) или плейлист на ютубе. Смотришь, запоминаешь про создание/изменение таблиц, первичные/внешние ключи, инсерты, апдейты, делиты, селекты с типами джойнов и подзапросами. Прорешиваешь задачи ( https://www.sql-ex.ru ). Но прям все задрачивать не надо. Придумываешь схему БД для какого-нибудь книжного магазина или для социалочки, причём схема нормализована хотя бы до третьей нормальной формы. Пишешь соответствующий пет-проект без юзания ORM, тупо голыми запросами и смотря, как это принято делать в твоём языке. Всё, дальше опыт и stackoverflw.
Аноним 08/12/20 Втр 21:32:28 187613657
>>1876132
Спасибо анонче. Жаль, что все собеседования на этой неделе. Буду грызть как могу.
Аноним 09/12/20 Срд 19:33:29 187684458
полигон.jpg 182Кб, 976x1184
976x1184
Добрый вечер, аноны.
Тут такое дело: за этот вузовский курс не было НИ ОДНОЙ, СУКА, ЛЕКЦИИ, а индивидуальное надо каким-то образом сделать. И вот, я начал с того, что нарисовал ИЛМ, в правильности которой очень сомневаюсь. Ибо тут, например, есть такой момент:

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


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

И вообще, аноны, что скажете по поводу нормализации, связей между таблицами и т.п.? Сойдет или нет?
Аноним 09/12/20 Срд 21:08:42 187691759
>>1869683
> В смысле область бд полудохлая?
она не полудохлая, она, если говорить о программировании, давно и непоправимо сдохла. последние 20 лет никто, находясь в здравом уме, в новом проекте не запиливает бизнес-логику на уровне БД. осталось одно дикое легаси которое писали чуваки которым щас по 70 лет и прикладные околоадминистративные задачи.
Аноним 09/12/20 Срд 21:21:01 187692060
Объясните что за базы данных information_schema и test в mariadb. Не могу найти информации по этой теме.
Аноним 09/12/20 Срд 22:07:11 187695861
>>1876920
> information_schema
Гугли "словарь данных", когда поймёшь эту концепцию, станет понятно, для чего эта БД.

> test
Хз, не трогай.
Аноним 10/12/20 Чтв 01:57:36 187709562
>>1876844
Нет в заказе ненужен. Непонятно зачем таблица технология изготовления. Она должна находится не между складом, а отдельным линком либо за складом. Да и вобще лекарство это справочник, оно должно смотреть в рецепт, а технология за ней. Представь ситуацию когда лекарства нет на складе, но есть в рецепте. Вобщем погугли схему снежинка
Аноним 10/12/20 Чтв 19:14:15 187752763
image.png 120Кб, 226x289
226x289
>>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
Аноним 10/12/20 Чтв 19:49:58 187754664
Аноним 10/12/20 Чтв 22:50:37 187771165
image.png 33Кб, 900x579
900x579
Здарова пацаны
Пилю бд для онлайн магазина (вообще впервые пилю бд) и вот возник вопрос. У меня есть таблица пользователей и таблица товаров. Теперь мне нужно зафигачить корзину. Я сделал таблицу со столбцами id - user_id - product_id - amount. Но погуглив, я увидел что некоторые аноны product_id и amount выносят в отдельную и связывают их. Зачем это нужно?

Пример реализации корзины который я нашел в инете
Аноним 10/12/20 Чтв 22:54:47 187771466
И еще сразу один вопрос. Я запускаю postgresql на локалхосте через докер, но уже второй раз бд сама по себе полностью удалилась. Точнее сама бд как бы есть, но таблиц в ней нет. Полагаю что это проиходит из-за того что я нажимаю кнопочку "обновить программы" в ubuntu и она обновляет либо psql либо docker. Я прав? И как избежать этого в дальнейшем
Аноним 11/12/20 Птн 00:59:25 187776467
>>1877711
> Goods
В магазине товары тоже не бесконечны, поэтому поле количества в ней тоже нужно.
> OrderState
Это может быть излишним, в большинстве СУБД есть поддержка enum-ок.
> OrderLine
Не понятно, зачем дублировать цену товара сюда. Разве что у тебя предполагаются какие-то наценки/комиссии, зависящие от времени,, но в таких случаях сумма скорее будет заранее подсчитана и храниться в таблице заказов, а не для каждой строки заказа отдельно.

>>1877714
Возможно, ты хранишь данные не в volume, а прямо в контейнере, и если контейнер удалится, данные пропадают и в новом контейнере не видны.
Аноним 11/12/20 Птн 10:50:20 187790268
>>1869616 (OP)
В таблице хранятся номера телефонов как varchar, нужно найти в таблице строку с подходящим номером, но вот незадача: в базе номера лежат номера в строгом формате: начинаются с 7 (русские номера), 11 знаков, никаких скобок и дефисов; а извне может придти любой телефон, скажем начинающийся с 8. Я могу отфильтровать на бэкенде всякие дефисы и скобки, но как делать эффективный запрос в базу, чтобы найти номер несмотря на то, что он будет начинаться не с 7?
Аноним 11/12/20 Птн 11:03:00 187790569
>>1877902
Использовать регулярку и предикат like?
Аноним 11/12/20 Птн 12:01:19 187793670
Аноним 11/12/20 Птн 12:05:40 187793971
>>1877936
хотя я видел "прод", где создали базу юзеров в первой попавшейся базе куда было возможно записывать.
И продолжают так работать.
10 лет.
Аноним 11/12/20 Птн 14:54:09 187809472
>>1877902
Я тут в одном из прошлых тхредов предлагал использовать left вместо like, в итге был обоссан анонами. Вобщем like с индексмо работает довльоно быстро.
Аноним 11/12/20 Птн 23:25:30 187848473
>>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 к записей в год при нормальном проектировании любая реляционка выдержит как нефиг делать (советую постгрес). И будет во много раз быстрее тормознутой монги.
Аноним 11/12/20 Птн 23:37:56 187849574
>>1878484
И еще -- если схема БД хотя бы мало-мальски сложная (что часто бывает в кровавом тырпрайзе), скажем кол-во табличек становится больше 10 -- не пожалей и раскошелься на какой - нибудь софт, позволяющий визуально осмотреть ее. Потыкать на табличку, посмотреть на связи. Плюс менять ее очень просто и в конце она генерит тебе большой запрос, создающий твою БД. Это просто незаменимая штука в подобных делах. Не реклама, но сам я пользуюсь DbSchema.

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

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

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

http://hibernate.org/search/

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

https://lucene.apache.org/

база при этом вообще неважна, хоть дерби или h2 используй. она нужна только как хранилище данных если нужно будет поисковый индекс перестроить, как я уже говорил если все правильно настроить к ней запросов вообще не будет.
Аноним 12/12/20 Суб 12:39:08 187867676
>>1878484
> Если у тебя есть фильтры, которые могут быть задействованы только вместе (скажем пользователь выбирает фильтр x, потом у него появляется возможность выбрать фильтр y и только после этого фильтр z)

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

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

> Если есть колонка, в которой хранится CLOB или BLOB
есть мнение что файлы в БД вообще хранить некошерно и для этого нужно использовать отдельное файловое хранилище
Аноним 14/12/20 Пнд 05:42:04 187998277
>>1874862

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

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

это примерно как Жаба с гарбаджъ коллектором,
которую придумали бля тех кто не смог Цэ Кресты
Аноним 14/12/20 Пнд 05:45:58 187998478
>>1878495

ERWin

а там глядишь и слово "нормальизация" встретицца.
Аноним 14/12/20 Пнд 10:25:09 188006279
>>1879984
> ERWin
охуеть ты некрофил

любая нормальная иде умеет таблички рисовать, но за последние лет пять лично я ни разу этим не пользовался, абсолютно бесполезная хуйня как по мне.
Аноним 14/12/20 Пнд 11:20:40 188009080
Аноны, есть Postgres, хочу запилить гео-распрелеленную систему. В сторону каких решений смотреть?
Думаю над мульт мастером, нагуглил и попробовал Bucardo, но может анон знает что-то поинтересней?
Аноним 15/12/20 Втр 14:00:23 188105881
image.png 7Кб, 227x220
227x220
Как сделать такое в Mysql?

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

Нужно сделать такую хуйню. У пиццы 5 ингридиент, ей надо взять 0.2 (20 грамм), 0.5, 1.2, 1.6, 2 из таблицы два разных игридиентов.
Без понятия как такое провернуть.

Аноним 15/12/20 Втр 14:17:48 188107182
>>1881058
умножение в школе еще не проходили?
15/12/20 Втр 14:19:14 188107383
>>1881071
Сука, только зашел и уже тупорылый еблан нарисовался
Аноним 15/12/20 Втр 14:23:01 188107584
>>1881058
>Как сделать такое в Mysql?

ХРАНИМКИ
Аноним 15/12/20 Втр 16:54:36 188118185
>>1881073
Тупорылый еблан тут ты. Пришел с тупым вопросом и сразу шлнеш мимокрока нахуй. Сам решай свои лабы, долбаеб.
15/12/20 Втр 16:57:57 188118586
>>1881181
Да ебальник завали хуйло, стоите друг друга, долбаебы ссаные
Аноним 15/12/20 Втр 20:01:50 188137387
>>1881058
Попробуй умножить.
Аноним 15/12/20 Втр 20:26:22 188138488
>>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)
)
или хранимкой.
Аноним 15/12/20 Втр 20:30:24 188138589
>>1881384
> интгредиентах
> ingedients
> intedient
У меня кстати половина кнопок на клавиатуры заедает, печатать что-то - боль.
Аноним 17/12/20 Чтв 22:57:11 188310890
>>1877905
Так мне че-то самому интересно: регулярок как таковых же нет в sql? Там есть синтаксис для LIKE но он уебищный и во много уступает регуляркам. Как тот же номер телефона там найти?
Аноним 18/12/20 Птн 00:16:51 188314491
>>1883108
Есть как минимум в оракле, что-то своё должно быть в других СУБД. Это нестандартная для SQL фича.
Аноним 18/12/20 Птн 00:20:19 188314892
>>1883108
>Как тот же номер телефона там найти
sqlalchemy:

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

))))))
Аноним 18/12/20 Птн 16:58:27 188369993
image.png 16Кб, 237x452
237x452
Сап аноны. Делаю бд для онлайн магазина. Каталог с возможностью добавления подкатегорий (за это отвечают столбцы parent_id и is_parent в caregories). Какие ошибки, что можно исправить? Буду благодарен за любую критику.
P. S. бд пилю впервые
Аноним 18/12/20 Птн 17:00:01 188370294
>>1883699
картинки к продуктам храню в файловой системе, для каждого продукта есть папка с id в качестве названия. Не нашел пока другого способа, что подскажете по этому поводу?
Аноним 18/12/20 Птн 17:14:30 188371995
>>1883699
Норм.
>>1883702
Лучше в файловой системе, скорее всего, будет работать быстрее, чем если хранить блобы в БД. Раздавать каким-нибудь нгинксом.
Аноним 18/12/20 Птн 18:19:43 188379196
>>1883719
>Раздавать каким-нибудь нгинксом.
типа для картинок отдельно сервак поднять?
Аноним 18/12/20 Птн 18:28:45 188380097
>>1883791
Да, но вообще от нагрузки зависит, для 3.5 анонов хватит и основного приложения.
Аноним 18/12/20 Птн 18:29:45 188380298
Аноним 19/12/20 Суб 02:49:06 188431299
Аноним 20/12/20 Вск 10:17:42 1885240100
Аноним 20/12/20 Вск 13:36:01 1885369101
>>1869616 (OP)
Сап, аноны. Заранее прошу простить, если не по теме пишу, просто хз, куда ещё писать. Нужен человек, которых разбирается в PL\SQL

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

Это всё не бесплатно, конечно. Если есть тут умельцы-молодцы, то в ответе на пост пишите контакт в телеге
Аноним 20/12/20 Вск 17:38:23 1885550102
изображение.png 628Кб, 640x480
640x480
>>1885369
надо тебе ,а телегу оставлять должны мы, какой хитрый
Аноним 20/12/20 Вск 17:47:12 1885555103
>>1885550
аноны, подкиньте, пожалуйста, годный курс по power bi
чтоб быстро и эффективно въехать в тему
Аноним 20/12/20 Вск 18:40:15 1885594104
Аноним 20/12/20 Вск 20:52:13 1885664105
>>1877902
Если нет регулярок:
TRANSLATE(phone, TRANSLATE(phone, '0123456789', ''), '');
Удаляешь всё что не является цифрой. Дальше можно первую 8 заменить на 7 и сделать из этого функциональный индекс или триггер-нормализатор телефонов при вставке в таблицу.
Аноним 20/12/20 Вск 21:17:04 1885700106
>>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);

Но вообще лучше сделать нормализацию на бэкенде (и для каждой страны свою)
Аноним 21/12/20 Пнд 11:57:03 1886036107
>>1869616 (OP)
Подкиньте годноту для вката в проектирование баз данных.
В частности, где досконально поясняется за модели данных,
и за способы преобразования иерархической и сетевой модели данных в реляционные, и возможно - между собой.
Как правильно спроектировать реляционную базу данных и как её нормализовать, и вот это вот всё.
Аноним 21/12/20 Пнд 12:40:00 1886065108
У меня есть своя бд из трёх таблиц. В одной из таблиц хранятся email, который должен быть уникальным. Как написать в sql(sqlite) код так, чтобы при ошибке записи(email не уникален) он удалил только что внесённые данные в другие таблицы и вышел? Я так понял надо использовать savepoint и rollback, но у меня нихуя не работает
Аноним 21/12/20 Пнд 13:07:30 1886083109
>>1886065
> при ошибке записи(email не уникален) он удалил только что внесённые данные в другие таблицы и вышел
Транзакции называется. Начинаешь транзакцию через BEGIN или SAVEPOINT, выполняешь запросы, если один из запросов свалился с ошибкой, делаешь ROLLBACK, если дошли до конца без ошибок, делаешь COMMIT.
Но это если ты вручную работаешь в консольке sqlite. Если ты делаешь это из какого-то приложения, у тебя там скорее всего будет механизм управления транзакциями, где ты в начале подключаешься к БД, запускаешь транзакцию вызовом нужной функции, делаешь запросы, в конце коммитишь или откатываешь. Важно, что там скорее всего будет включён auto-commit, его надо будет выключить.
Аноним 21/12/20 Пнд 13:15:59 1886090110
Аноним 21/12/20 Пнд 14:13:54 1886124111
>>1886090
Не, он же на непонятном. Только что погуглил переводы на русский, ссылка неактивна.

У меня тут парочка вопросов назрела.
Возможно ли расширить таблицу, не добавляя поля к изначальной таблице, а создавая новую?
Возможно ли создать таблицу с кучей полей, из кучи таблиц, где есть только ID и одно поле?
То есть, имеет ли смысл, на каждое поле по таблице сделать, а потом увязать 1 к 1?
Аноним 21/12/20 Пнд 15:24:37 1886196112
>>1886124
Не совсем понятно, о чём речь.
> Возможно ли расширить таблицу, не добавляя поля к изначальной таблице, а создавая новую?
Одним запросом это не сделать. Нужно явно создать новую таблицу так же, как создавалась старая таблица, затем скопировать в неё нужные данные из старой с помощью такого запроса: https://www.w3schools.com/sql/sql_insert_into_select.asp
> Возможно ли создать таблицу с кучей полей, из кучи таблиц, где есть только ID и одно поле?
Возможно, но с 1 к 1 обычно так не делают и хранят всё в одной таблице. Разве что для логического разделения сущностей, но это смотря как моделировать предметную область.
Аноним 21/12/20 Пнд 17:32:36 1886314113
Поясните, чё такое функции в SQL PL?

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

Скажите, в чём вообще профит использовать их и в каких проектах оно нужно? Я это только в универе сдавал, а потом пошёл работать на web backend. Для каких вообще юзкейсов надо знать PL? Или это только для тех у кого Postgres не oracle?
Аноним 21/12/20 Пнд 17:43:04 1886323114
>>1886314
> Поясните, чё такое функции в SQL PL?

В смысле не чё такое, а где применяются
Аноним 21/12/20 Пнд 17:48:51 1886330115
>>1886314
У нас хранимые функции/процедуры часто юзаются в скриптах миграции, где простым DML заебёшься писать кучу типовых инсертов/апдейтов. Ещё есть OLAP-база, где в таких процедурах уже логика.

> для тех у кого Postgres не oracle
Да.
Аноним 22/12/20 Втр 13:46:04 1887058116
>>1869616 (OP)
Связываются ли таблицы непосредственно внутри базы данных,
или они связываются уже на уровне логики работы с базой - через запросы какие-то вроде JOIN-хуеин?
Может ли быть внутри одной базы данных блок взаимосвязанных таблиц, которые не связаны с другими таблицами?
Может ли быть несколько баз данных в одной базе данных?
Можно ли сконвертировать всю файловую систему в базу данных?
Аноним 22/12/20 Втр 13:48:46 1887062117
>>1887058
И ещё вопрос, в догонку.
Имеет ли смысл использовать вместо базы данных, кучу папок с названием таблиц, и кучу файлов в них, со значениями строк таблиц в JSON?
Будет ли такая шняга работать шустрее, чем запросы к БД?
Будет ли это проще, нежели пердолинг с сиквелом и CУБД?
Аноним 22/12/20 Втр 14:08:29 1887079118
>>1887058
> Связываются ли таблицы непосредственно внутри базы данных,
> или они связываются уже на уровне логики работы с базой - через запросы какие-то вроде JOIN-хуеин?
Да, связываются в виде констреинтов. Ты можешь создать его явно, либо он создастся неявно при указании foreign key, когда создаёшь таблицу. Но технически это не обязательно, констреинты нужны только для проверок, что такой ключ есть в таблице, на которую ссылаются (ссылочная целостность), а так их можно вообще не создавать и делать всё на уровне логики.
> Может ли быть внутри одной базы данных блок взаимосвязанных таблиц, которые не связаны с другими таблицами?
Да, хоть вообще никак таблицы не связывай, никаких ограничений на это нет.
> Может ли быть несколько баз данных в одной базе данных?
Нет. Зато есть понятие схем, их может быть в одной БД несколько. Правда, некоторые СУБД, например, mysql, эти понятия отождествляют.
> Можно ли сконвертировать всю файловую систему в базу данных?
Зачем? Теоретически можно представить файловую систему в виде реляционной модели и написать скрипт для наполнения такой БД.
>>1887062
Только если у тебя там хранятся совсем простые данные, вроде настроек или чего-то ещё, чего немного и не жалко потерять. Для большего нельзя. Работать, скорее всего, для большинства задач будет медленнее. У тебя не будет ни транзакций, ни ссылочной целостности, ни индексов, ни оптимизации. Будет, конечно, проще, но это единственный плюс.
Аноним 22/12/20 Втр 17:30:12 1887288119
>>1887079
>Да, связываются в виде констреинтов. Ты можешь создать его явно, либо он создастся неявно при указании foreign key, когда создаёшь таблицу.
>Но технически это не обязательно, констреинты нужны только для проверок, что такой ключ есть в таблице,
>на которую ссылаются (ссылочная целостность), а так их можно вообще не создавать и делать всё на уровне логики.
Ну, эта связь физически есть внутри базы,
в том плане что задан ли где-то, в базе данных - тип связи (1 к 1, 1 ко многим, многие к 1, многие ко многим),
или же эта связь задаётся на уровне запроса, а в базе данных - просто таблицы,
и ID в качестве поля - в одной таблице, и ключевого поля с ID - в другой таблице?

>Да, хоть вообще никак таблицы не связывай, никаких ограничений на это нет.
>Нет. Зато есть понятие схем, их может быть в одной БД несколько. Правда, некоторые СУБД, например, mysql, эти понятия отождествляют.
Вот это хотел узнать. Ведь блок взаимосвязанных таблиц - это и есть база данных для какого-нибудь проекта (модель данных проекта).
И в файле .db могут быть модели данных разных проектовы - что впрочем и понимается как разные "базы данных" для разных проектов
(а не сам файл базы, ведь она может быть вообще в облаке, и может содержать множество никак не связаных друг с другом моделей данных).

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

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

>>1887062
>>Имеет ли смысл использовать вместо базы данных, кучу папок с названием таблиц, и кучу файлов в них, со значениями строк таблиц в JSON?
>Только если у тебя там хранятся совсем простые данные, вроде настроек или чего-то ещё, чего немного и не жалко потерять.
>Для большего нельзя. Работать, скорее всего, для большинства задач будет медленнее.
>У тебя не будет ни транзакций, ни ссылочной целостности, ни индексов, ни оптимизации. Будет, конечно, проще, но это единственный плюс.
Аа, ну да. Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной,
но это не значит что реляционную можно свести к иерархической (быть может к сетевой можно, но опять же - не знаю как).
Если значение поля в строчке таблицы базы данных - будет содержать BLOB в 500 мегабайт, то и JSON-файл со строчкой такой таблицы, будет весить 500 метров,
и чтобы проверить по условию значение другого поля в этой строчке, придётся грузить 500 метров...
Если условие не выполнено - другой файл грузится, ещё 500 метров, короче пиздец, и пижже БД.
Аноним 22/12/20 Втр 17:39:25 1887300120
>>1887288
>Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной,
>но это не значит что реляционную можно свести к иерархической (быть может к сетевой можно, но опять же - не знаю как).
Если реляционную модель можно свести к сетевой, то и к иерархической, походу - но придётся дублировать эти ебучие данные.
Аноним 22/12/20 Втр 17:44:30 1887305121
Помогите плз задачку решить с 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)
Но вот как сделать их чередование я хз. Так что либо помогите допилить мое решение, либо тупо скиньте свое, в любом случае поклон вам в ноги
Аноним 22/12/20 Втр 17:52:37 1887316122
>>1887288
> в том плане что задан ли где-то, в базе данных - тип связи (1 к 1, 1 ко многим, многие к 1, многие ко многим)
Нет, это на уровне логики/запроса.
> Ведь блок взаимосвязанных таблиц - это и есть база данных для какого-нибудь проекта
База данных - это более конкретная вещь, а не просто абстрактное понятие для набора таблиц. Это именно общее хранилище для разных сущностей, взаимосвязанных или нет. "Модели" может и разные, но база в любом случае одна. Например, "удалить базу данных" значит удалить все эти модели одновременно, которые якобы не связаны. Но это с практической точки зрения, принятой в терминологии SQL. Терминология может отличаться в других подходах.
> Я где-то слышал, что файловая система - это и есть база данных. Но это не точно.
Можно и единственный текстовый файл со списком чего-либо назвать базой данных, и в каком-то смысле это будет правильно.
> Но, и иерархическую, и сетевую модель данных, насколько я понимаю - можно свести к реляционной модели данных (правда не понимаю как?).
Например, есть такая таблица: id | parent_id | is_file | name
id - просто айдишник, parent_id - ссылка на запись в этой же таблице, is_file - признак файла/каталога, name - название. И так можно строить иерархии. С сетевой моделью уже будет отдельная таблица связей многие-ко-многим. А содержимое файлов хранить в отдельной таблице, которая будет ссылаться на первую таблицу.
> почему бы не хранить данные - в реляционной базе данных, вместо файловой системы
Иногда БД - это лишний оверхед. В БД на первое место ставится надёжность, чтобы во что бы то ни стало не проебать данные, и пусть запрос ради этого хоть 100 лет выполняется. А если ты хочешь просто скачать пак с котиками, то тебе может быть всё равно, что процесс копирования остановится раз в много лет на 90%, проще скопировать заново либо вообще забить.
> И если так, то почему бы не заебенить глобальную базу данных, где все файлы и их фрагменты, хранились бы в одном пиздатом облаке,
Хотя бы из-за медленной скорости интернета по сравнению с жёстким диском. Есть шутка про то, что быстрее всего данные передаёт грузовик с жёсткими дисками.
> Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной, но это не значит что реляционную можно свести к иерархической
Да всё ко всему можно в предельном случае, лишь бы была программа, которая может это прочитать и представить в нужном виде.
Аноним 22/12/20 Втр 17:59:05 1887322123
>>1869616 (OP)
Почему про встраиваемую SQLite в ОП-шапке ни слова? Опенсорц же? Или просто - ОП-хуй?
Аноним # OP 22/12/20 Втр 18:09:29 1887334124
>>1887322
> SQLite
Надо добавить, но там много не накопать в отрыве от ЯПов.

> Опенсорц же?
Зато у меня там много проприетарщины.

> ОП-хуй?
Безусловно.
Аноним 22/12/20 Втр 18:20:15 1887350125
>>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-секторы.
Значит надо два файла, походу, и репликацию заебенить. И ремап. Тупая, короче, идея.

>> Выше я писал, что иерархическую и сетевую модель, вроде можно свести к реляционной,
>>но это не значит что реляционную можно свести к иерархической
>Да всё ко всему можно в предельном случае, лишь бы была программа, которая может это прочитать и представить в нужном виде.
Что ещё не заебенили? Мне что-ли нарукожопить эту хуйню?
Аноним 22/12/20 Втр 18:25:46 1887354126
Как в sqlite сделать поиск русских слов по таблице регистронещависмо?
Аноним 22/12/20 Втр 18:29:47 1887361127
Аноним 22/12/20 Втр 18:33:23 1887364128
>>1887350
> репликацию
Оба файла могут попасть на bad-сектора, и если какой-нибудь заголовок похерится, куча данных проебётся. Не стал бы я хранить огромные бинарные файлы на дешёвом диске.
> Что ещё не заебенили? Мне что-ли нарукожопить эту хуйню?
Обычно нет смысла, делать из буханки автобус, вместо этого берут другой тип БД.
Аноним 22/12/20 Втр 18:33:39 1887365129
Аноним 22/12/20 Втр 18:34:12 1887366130
Аноним 22/12/20 Втр 18:34:13 1887367131
>>1887365
А, ну да, только с латиницей раотает.
Аноним 22/12/20 Втр 19:53:31 1887448132
>>1887305
Чото ты херню каку-то делаешь. Через оконные функции попробуй. Делаешь row number(простой и desc) для каждой таблицы до обьеденения, потом по нему сортируешь, если нужен особый порядок сортировки, меняешь нумерацию на основе обоих столбов через CASE.

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

Аноним 22/12/20 Втр 22:32:21 1887540133
Работал с гринпламом кто? Или тут одни пузаны из банков?
Аноним 22/12/20 Втр 23:06:36 1887558134
>>1886314
> Скажите, в чём вообще профит использовать их и в каких проектах оно нужно
никакого профита нет, только легаси и административная хуйня типа миграции данных и распределения данных при партиционировании. за использование скриптов субд в бизнес-логике руки отрывают лет 20 уже как.

это остатки хайповой технологии 50-летней давности, когда была идея фикс писать приложения прямо в БД. сейчас код на плскл это то же самое что код на коболе.
Аноним 22/12/20 Втр 23:12:48 1887563135
>>1887062
>Имеет ли смысл использовать вместо базы данных, кучу папок с названием таблиц, и кучу файлов в них, со значениями строк таблиц в JSON?
не имеет

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

> Будет ли это проще, нежели пердолинг с сиквелом и CУБД?
будет сложнее на два порядка
Аноним 22/12/20 Втр 23:25:47 1887572136
>>1886314
Представь, что тебе нужно рассчитать много данных, примерно, 1 тер. Плюс должен быть пользователь который задаёт алгоритм расчёта руками через интерфейс. Как сделать это без хранимок?
Аноним 22/12/20 Втр 23:30:09 1887574137
>>1887572
> Как сделать это без хранимок?
на любом нормальном ЯП, например, не?
Аноним 22/12/20 Втр 23:31:36 1887575138
>>1887574
Ты питоном собрался 1 терабайт данных обрабатывать? А субд какую юзать будешь?
Аноним 22/12/20 Втр 23:32:19 1887577139
>>1887572
Вот и получается, что юз-кейс хранимок - это только аналитика.
>>1887574
Грузить терабайт в ОЗУ, считать и сохранять обратно, так?
Аноним 22/12/20 Втр 23:34:26 1887579140
>>1887577
>Грузить терабайт в ОЗУ
Медленно и зачем?
Аноним 22/12/20 Втр 23:52:05 1887584141
>>1887575
> Ты питоном собрался 1 терабайт данных обрабатывать?
ну если он поддерживает стрим данных/курсоры то можно и питоном.

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

>>1887577
>Грузить терабайт в ОЗУ, считать и сохранять обратно, так?
ты задачу то опиши, что за обработка такая где нужно терабайт в память грузить и как с этим может справится субд?
Аноним 23/12/20 Срд 00:01:46 1887587142
>>1887584
> такая где нужно терабайт в память грузить
Например, тебе нужно посчитать зп которая от продаж продаванов крупного ритейла. Можешь считать, что пользователь самостоятельно задаёт алгоритм расчёта. Для этого пользователю необходим интерфейс, поэтому это далеко не BI отчёт.
>постгрес, оракл, мсскл
Любой из, зависит от источника данных
>как с этим может справится субд
Вполне легко?
Аноним 23/12/20 Срд 00:20:17 1887598143
НА ВОПРОСЫ НИКТО НЕ ОТВЕЧАЕТ
@
SQL НИКТО НЕ ОБСУЖДАЕТ
@
ДА И ВОБЩЕ НАМ ВАШ SQL НАХУЙ НЕНУЖОН
Аноним 23/12/20 Срд 00:30:59 1887605144
>>1887598
SQL совершенен, вот и обсуждать нечего.
Аноним 23/12/20 Срд 09:18:27 1887801145
>>1869616 (OP)
>>1886036
>>1887288
>>1887300
>>1887316

Если иерархическую и сетевую модель данных можно сконвертировать в реляционную, и наоборот,
то можно ли нейросетевую модель данных представить в виде реляционной модели?!!
Будет ли она фурычить также как фурычат мозги?
Аноним 23/12/20 Срд 10:52:34 1887841146
>>1887587
> Например, тебе нужно посчитать зп которая от продаж продаванов крупного ритейла.
и зачем тебе для этого хранимка? это стандартнейший кейс для сервис-лэйера приложений, нафига его в уровень бд пихать?
Аноним 23/12/20 Срд 11:02:39 1887844147
>>1887587
> Вполне легко?
ты не понимаешь вопроса. если тебе нужно обрабоать 1 тб данных алгоритмом, который требует грузить все данные в память, бд обосрется так же как и обычное приложение.

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

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


Аноним 23/12/20 Срд 11:09:44 1887849148
Аноним 23/12/20 Срд 11:26:57 1887863149
Нужно ли для сис админа знать sql?
Аноним 23/12/20 Срд 11:43:49 1887896150
>>1887849
> MVP
> В мире стартапов и начинающего бизнеса денег нет. Есть только немного человеческого ресурса. Спека? Пффф... Это непозволительная роскошь. Тестеры? Пфф... Девопсы? Ну вы поняли.
> Я храню все данные в файловой системе, как простой json файл. Это очень быстро, просто, и это отлично работает.
> RAMа так много, что диск нужен лишь меньшинству

И это пишет джавист? Раз ему нужно срочно клепать дохуя неподдерживаемого говна, выбор жабы вызывает много вопросов. А почему тогда не пыха и js?
Аноним 23/12/20 Срд 11:51:29 1887912151
>>1887863
Смотря какому, кому-то нужно.
Аноним 23/12/20 Срд 12:12:59 1887932152
>>1887896
А хуй знает, спроси его. Но как я понял из статьи, БД и СУБД не нужны, потому что дохуя ебалы, и можно сделать всё проще, на низком уровне.
Аноним 23/12/20 Срд 12:17:31 1887933153
>>1869616 (OP)
Аноны, подскажите, как лучше быть в такой ситуации.
Я тут делаю бэк к одному приложению. Оно подключено к бд, которая будет меняться откуда-то ещё, т.е. не только изнутри приложения.
И, значит, есть форма, где на фронте пользователь будет создавать новые объекты в одной мега-большой таблице. В этой таблице около 70 полей, из низ 30 ограничены вариантами из валидационных таблиц. Допустим, в одном поле выбирается из списка допустимых стран, в другом - какой-нибудь там тип кредита или опциона или ещё чего. Все эти типы могут со временем меняться, так что не захардкодить, а сами данные в базе могут меняться откуда-то ещё, извне моего приложения, так что и закэшировать нормально не выйдет.
И вот я не хочу делать 30 селектов к базе, чтобы получить допустимые значения по этим валидационным таблицам. Как мне быть, какой лучше составить запрос? Или тут лучшим вариантом будет сделать какую-то вьюху на стороне базы, которая бы объединяла эти данные и обновляла автоматически, а я дергал уже её? Хотелось бы без этого обойтись
Аноним 23/12/20 Срд 12:59:24 1888013154
>>1887896
да это переводная статья десятилетней давности. написанная на хайпе всяких монгодб и прочих мусоросборников. доводы что там описаны обоссаны по сто раз уже.
Аноним 23/12/20 Срд 13:04:05 1888018155
Аноним 23/12/20 Срд 13:16:22 1888029156
>>1887932
> Но как я понял из статьи, БД и СУБД не нужны, потому что дохуя ебалы, и можно сделать всё проще, на низком уровне.
нет. смысл статьи - если ваше говно умрет через 1 год то зачем заморачиваться?

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

> Я храню все данные в файловой системе, как простой json файл. Это очень быстро, просто, и это отлично работает.
> 100К активных пользователей — ровно столько я могу обслуживать с 1 ГБ RAM на виртуалке за 10 у.е.
ололо блядь. и такой пиздеж всю дорогу

любая самая простая субд типа h2 просто порвет его json файлы в оперативке по производительности в клочья, когда потребуется сделать что-нибудь посерьезнее выборки пользователей по ключу. потому что тупо свалить все говно в оперативку - это не значит сделать выборку данных быстрее. чтобы оно быстро выбиралась нужно строить индексы, деревья и использовать продвинутые алгоритмы поиска. а если тупо массив в памяти держать и перебором его обходить каждый раз когда потребуются данные - это будет просто пиздец как медленно.
Аноним 23/12/20 Срд 13:17:18 1888033157
>>1888013
Ладно ещё монга, он же вообще предлагает всё хранить тупо в файлах и ОЗУ. Как деды в середине прошлого века.
Аноним 23/12/20 Срд 13:17:43 1888036158
>>1887933
> И вот я не хочу делать 30 селектов к базе
почему, в чем проблема сделать 30 селектов?

Аноним 23/12/20 Срд 13:18:41 1888037159
Аноним 23/12/20 Срд 13:25:04 1888049160
>>1888036
30 селектов - это 30 реквестов к удаленной базе. Это долго.
Аноним 23/12/20 Срд 13:25:39 1888051161
>>1888049
долго - это сколько в миллисекундах?
Аноним 23/12/20 Срд 13:27:45 1888058162
>>1888051
Ну вот с моего локального компа выходит по 0.068 секунд на один такой запрос. На проде всё будет быстрее, я думаю, раз в 10-20, так как всё в одном клауде находится. Но всё равно, это 30 запросов, мне кажется, что можно сделать как-то по-другому, как-то лучше.
Аноним 23/12/20 Срд 13:37:29 1888073163
>>1888058
> Но всё равно, это 30 запросов, мне кажется, что можно сделать как-то по-другому, как-то лучше.

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

еще решения:

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

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

3) сделай единую точку входа для получения и обновления данных и помести туда кеш.
Аноним 23/12/20 Срд 14:17:55 1888126164
Аноним 23/12/20 Срд 15:23:26 1888223165
>>1887844
Т. е. ты считаешь, что лучше писать курсоры, которые запускают SQL? Ты уверен, что это будет красивей?
Аноним 23/12/20 Срд 16:01:51 1888259166
>>1888223
> Т. е. ты считаешь, что лучше писать курсоры, которые запускают SQL? Ты уверен, что это будет красивей?
найти задачу в которой тебе действительно потребуются курсоры - это еще надо постараться.

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


Аноним 23/12/20 Срд 16:20:44 1888273167
>>1888259
Так если мы засовываем логику в запросы, то зачем нам вызвать запросы на сервере приложений? Процедурный sql в данном плане гораздо удобнее.
Аноним 23/12/20 Срд 16:45:53 1888290168
1608731152866.png 10Кб, 603x354
603x354
Аноны, помогите, плиз, решить задачу, второй день не могу справиться. Хотя бы идею подкиньте. :'с

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

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

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

ЧЯДНТ?
Аноним 23/12/20 Срд 16:52:49 1888295169
image.png 433Кб, 1150x864
1150x864
>>1869616 (OP)
>>1887316
>С сетевой моделью уже будет отдельная таблица связей многие-ко-многим.
Являются ли связи - отдельными таблицами?
Если да, то можно ли где-то просмотреть примеры таблиц, для связей: "1 к 1", "1 к M", "M к 1" и "M к N"?
Как понять пикрил?
Возможно ли реализовать связь "M к N" при помощи одних лишь таблиц, без этих вот связей, которые сверху соединяют таблицы?

Дело в том, что я всё-ещё смотрю на них, на эти связи, как на что-то неведомое, и реально соединяющее эти вот ебучие таблицы.
Если этими связями, являются, просто, отдельные таблицы, с индексами то базара нет.
Ведь как мы уже выяснили ITT, никаких связей в реляционной БД может не быть вовсе, там могут быть тупо таблицы.
Но я всё ещё слабо представляю себе, как именно на них реализуется эти вот связи, неведомые.
Аноним 23/12/20 Срд 16:59:59 1888301170
>>1888295
>Являются ли связи - отдельными таблицами?
Да, если это многие ко многим там появляется ещё одна таблица.
>Возможно ли реализовать связь "M к N" при помощи одних лишь таблиц, без этих вот связей, которые сверху соединяют таблицы
Да, связи между таблицами это всего-лишь ограничения на изменения данных в этих таблицах.
>как именно на них реализуется эти вот связи
Почитай про ключи и констрейнты.
Аноним 23/12/20 Срд 17:02:43 1888304171
>>1888273
>>1888259
Более того - какая разница что ты дёргаешь - запросы или процедуры. Если код запросов повторяется, зачем плодить лишний код?
Аноним 23/12/20 Срд 17:13:58 1888319172
>>1888304
> Более того - какая разница что ты дёргаешь - запросы или процедуры. Если код запросов повторяется, зачем плодить лишний код?
какой лишний код? разница тут - в поддержке и разработке.

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

во вторых - любая задача, отличающая ся от джойна трех таблиц реализорванная например на PL/SQL - это нечитаемый пиздец. это практически неподдерживаемый код, который пишет один раз а при необходимости изменений переписывается с нуля.
Аноним 23/12/20 Срд 17:21:09 1888321173
>>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, при соединении таблиц в базе, - дремучий лес какой-то,
походу связываются эти таблицы - какими-то неведомыми механизмами, проприетарными,
копирастическими, и коммерчески-корпоративными, механизмами - код которых - закрыт, блядь.
Если их, эти связи можно просто реализовать таблицами, то тогда другой базар, а так - магия какая-то, за которую надо нести копирастам бабала.
Аноним 23/12/20 Срд 17:25:12 1888327174
>>1888321
> Это вся их суть? Я думал там глубже намного, тот же поиск связанных данных, например...
да, ты правильно говоришь, тот же постгрес сразу индексы на форенкеи строит

> за которую надо нести копирастам бабала.
чет-тебя понесло не туда
Аноним 23/12/20 Срд 17:33:38 1888340175
>>1869616 (OP)
В чём профит нереляционных моделей данных и нереляционных СУБД?
Аноним 23/12/20 Срд 17:34:43 1888342176
Аноним 23/12/20 Срд 17:44:27 1888362177
>>1888342
Тогда такой вопрос:
Возможно ли свести к реляционной модели все эти вот модели данных: https://ru.wikipedia.org/wiki/Модель_данных#Примеры
или есть среди них какие-то несводимые, которые если не пижже реляционной модели, то какие-то особенные дохуя?
Аноним 23/12/20 Срд 17:46:40 1888371178
>>1888319
> реализующий бизнес-логику
В таком случае нам нужно отталкиваться от определения бизнес логики. Вызов SQL кода питоном/жабой/php без процедур это бизнес логика? Если нет то да, нам нужно перенести логику в хранимки/триггеры. Аргумент от
>PL/SQL - это нечитаемый пиздец
не принимается так как в твоём случае от этого поста >>1887844
>хранимка - это всего лишь набор SQL-запросов, которые ты просто можешь вызвать из приложения
мы должны будем также корректировать SQL код те же яйца только в профиль, который без динамики действительно рано или поздно станет нечитабельным говном. Да и pl/sql вполне легко читать, нужно лишь уметь это делать.
Если же вызов SQL кода это не бизнес логика, то я с твоими предпосылками не согласен.

Аноним 23/12/20 Срд 17:47:20 1888373179
>>1888371
>Если же вызов SQL кода это не бизнес логика
Это бизнес логика*
Аноним 23/12/20 Срд 18:26:31 1888418180
>>1888362
к реляционной модели можно свести практически все. более того, любую реляционную модель можно всегда свести к трем таблицам.
только нахуя тебе все эти теоретические изъебства?

основная претензия к нереляционным базам заключается в том что в них очень хуёвая обработка связности и огромное дублирование данных, и огромные проблемы с их обновлением при большом объеме хранилища. а как только начинаются попытки решить эти проблемы то получаются велосипеды которые оракл изобрел еще полвека назад.
Аноним 23/12/20 Срд 18:49:04 1888446181
>>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

Аноним 23/12/20 Срд 19:04:58 1888465182
2020-12-2319-02[...].png 48Кб, 1363x900
1363x900
2020-12-2319-02[...].png 51Кб, 1325x956
1325x956
>>1888446
вот пожалуйста типичный пример функций на PL/SQL для обработки текстовых данных. даже не рискну вникать что тут написано, но уверен что на перле/питоне/яве это заняло бы строчек пять
Аноним 23/12/20 Срд 19:18:31 1888473183
>>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.
Ну и минимальные, базовые знания к проектированию этих вот баз данных,
разумеется, с возможностью их расширения, этих вот знаний, законспектированных.
Аноним 23/12/20 Срд 19:19:54 1888475184
image.png 462Кб, 920x832
920x832
>>1888473
Пикрил отклеилась.
Аноним 23/12/20 Срд 19:24:41 1888482185
>>1888473
> Вау! Чё реально, не более трех таблиц, у реляционной модели произвольной сложности? Как на пикрил, скажем.
да. таблица объекты(аттрибуты), таблица их значений, и таблица для связи объектов между собой. к этому можно свести абсолютно любую реляционную модель.
Аноним 23/12/20 Срд 19:31:04 1888491186
Как будет выглядеть запрос в mysql, если при существующем name, в её колонку amound добавляется +1.
Если не существует name, то добавить её, а amount оставить 1.

Загуглить не могу нормально, уже раз 15 попробовал.
Аноним 23/12/20 Срд 19:42:35 1888502187
SELECT id, x, SUM(SELECT count FROM boba WHERE id = yoba.id) FROM yoba
Поясните увальню, как этот SUM использовать?
Аноним 23/12/20 Срд 19:48:05 1888515188
>>1888491
bump

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

Все просто же, но нихуя не понятно.
Аноним 23/12/20 Срд 20:00:01 1888531189
>>1888515
select (case when name is null then amount + 1 else amount - 1 end) from ...
Как-то так, наверное
Аноним 23/12/20 Срд 20:10:08 1888542190
>>1888465
Лол, по моему это прям вообще интуитивно понятный код.
Аноним 23/12/20 Срд 20:13:08 1888549191
>>1888446
>это не ок, потому что ты не знаешь что это за calcMyGridSize и что он делает.
Ты не понял мою постановку задачи. Это не удивительно, скорее всего ты не работал в масштабных проектах и не знаешь зачем эти технологии нужны
Ты не сможешь написать обработку, потом что у тебя пк сгорит, если ты в хэшмэпе будешь обрабатывать больше 200 гигов. Нахуя тебе делать селект, если от тебя необходим расчёт?
Аноним 23/12/20 Срд 20:37:38 1888582192
>>1888549
> Ты не сможешь написать обработку, потом что у тебя пк сгорит, если ты в хэшмэпе будешь обрабатывать больше 200 гигов.
для этого есть бэтч лоадинг или курсоры или датастримы и тому подобное. но повторяю, ты покажи реально задачу, где нужно построчно пробегать по таблицам, в 99 процентах случаев это все спокойно заменяется групповыми и агрегатными запросами.

ты же сам написал
>хранимка - это всего лишь набор SQL-запросов, которые ты просто можешь вызвать из приложения
> мы должны будем также корректировать SQL код те же яйца только в профиль, который без динамики действительно рано или поздно станет нечитабельным говном
ну да, так и нужно делать. побочный эффект - адовая обработка данных, пример которых на скриншотах выше, заменяется функциями на нормальном языке.
Аноним 23/12/20 Срд 21:08:40 1888635193
>>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), тогда это вообще какая-то многомерная хуета получается, а не просто таблица.
Аноним 24/12/20 Чтв 10:31:06 1889020194
Поясните. Последовательность операций не меняющих содержимое базы считается за ТРАНЗАКЦИЮ?

незаметил новый тред сразу сорян
Аноним 24/12/20 Чтв 10:54:15 1889035195

>>1887572
Кажется, сейчас для этого моден хадуп.
Причем, изначальные цели сместились и для простого хранения есть clickhouse
Аноним 24/12/20 Чтв 11:01:00 1889038196
>>1888033
Так ему вообще хранить не надо. Эта штука, blynk, типа прокси для ардуинщиков. Данные передаются, но не записываются
Аноним 24/12/20 Чтв 12:56:36 1889120197
>>1889020
Всё считается транзакцией, даже если ты между бегином и коммитом вообще не выполнял запросов.
Аноним 24/12/20 Чтв 14:14:57 1889211198
>>1887558

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

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

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

>>1887572
А как эта ебень пишется и тестится? Какой воркфлоу? Миграции?
Аноним 24/12/20 Чтв 14:21:51 1889224199
>>1889035
>моден хадуп.
Для одного террабайта? Хадуп это про даталейки двх нового поколеня.
Аноним 24/12/20 Чтв 14:48:06 1889265200
>>1889224
> даталейки
Не зря сижу на дваче, постоянно узнаю что-то новое.
мимо
Аноним 24/12/20 Чтв 16:30:57 1889410201
Аноним 24/12/20 Чтв 17:28:24 1889506202
>>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)
)
)
Ищем сначала все игры, которые НЕ подходят - выпущены либо не американцами, либо в нечётных годах. Находим все транзакции, в которых покупались такие игры. Находим все аккаунты, к которым отностятся транзакции. Берём все аккаунты и исключаем из них аккаунты из неподходящими транзакциями. Берём логины по аккаунтам.
Аноним 24/12/20 Чтв 17:54:45 1889559203
>>1889506
Выглядит логично и красиво, но выдает пустой столбец логинов а логины должны быть. Но спасибо за ответ в любом случае
Аноним 24/12/20 Чтв 18:01:58 1889571204
>>1889559
Попробуй позапускать отдельные подзапросы, вдруг на каком-то моменте я начинаю делать что-то не то. Тут надо сидеть и разбираться, сам сходу ошибку не смогу найти.
Аноним 24/12/20 Чтв 18:12:18 1889585205
>>1889571
что-то не то судя по всему ниже этой строчки но это не точно
select account_id from transactions where account_id not in
Когда я убираю not, мне выдает список вообще всех логинов, то есть неподходящие видимо все. Но я могу ошибаться, только вкатываюсь в SQL и творю хуйню. Поковыряюсь ещё.
Аноним 24/12/20 Чтв 18:44:45 1889621206
>>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'
Аноним 24/12/20 Чтв 19:20:58 1889651207
>>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



Аноним 24/12/20 Чтв 19:53:19 1889683208
>>1889651
Спасибо, завтра попробую залупу
Чем принципиально твой вариант отличается от моего? Я не доебываюсь, просто хочу понять, что именно преподу могло не понравиться в моём запросе, при том, что запрос выдавал нужные логины.
Аноним 24/12/20 Чтв 21:32:51 1889791209
чем отлич классич БД от nosql?
для чего их создали?
Аноним 24/12/20 Чтв 21:49:49 1889816210
>>1889791
Тем и отличаются, что сделаны не так, как реляционные, а как-то по-другому. В реляционных у тебя таблицы, взаимосвязи через ключи, нормализация, транзакции, статическая схема. В NoSQL у тебя могут быть, например, хранилища JSON или XML, ключи-значения или даже графы.
Для чего это нужно - не везде требуется такая надёжность ценой скорости, как в реляционных. Например, key-value кеш в ОЗУ. который не страшно проебать при перезапуске сервера. Или какие-нибудь JSON-ки, которые можно восстановить из бэкапа (в предположении, что делать это придётся очень редко), делаемого раз в день, а остальное вычислить заново.
Аноним 24/12/20 Чтв 23:45:05 1889968211
>>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|


Аноним 24/12/20 Чтв 23:52:35 1889975212
>>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, эти значения могут быть и не равны, как в примере предыдущего поста.
Короче, отсюда и вопрос.
Аноним 25/12/20 Птн 03:36:03 1890076213
>>1889968
Чот ничо не понял. Зачем тебе третья таблица? Какой ещё порядок значений?
В любом случае для 1 к 1 хватит двух таблиц.
Связь 1 к 1 с двумя таблицами делается тупо хранением id первой таблицы во второй + констреинт, что во второй таблице id первой уникален, этим констреинтом можно гарантировать, что не будет больше одной записи, ссылающихся на одну и ту же запись в первой таблице (как 1 ко многим).
Таблица1:
- id
- другие столбцы
Таблица2:
- id
- таблица1_id -> таблица1.id UNIQUE
- другие столбцы

Правда, обычно 1 к 1 хранится в одной таблице.
Аноним 25/12/20 Птн 08:21:26 1890288214
>>1889683
Нужны два условия и год и игра. У тебя фильтр where применяется ко всему запросу.

Хотя у меня подозрение, что твой препод просто ебанный дед,которому нужно чтоб решили по евонному, через подзапрос. Но как известно любую задачу можно решить двумя способами, либо через подзапрос, либо джоинами.
Аноним 25/12/20 Птн 19:10:18 1890851215
>>1869616 (OP)
Котаны, у меня есть доступ на удаленный сервак, я могу там подключаться к местной БД (postgresql) и читать оттуда данные, но мой юзер не имеет права ничего создавать, редактировать или запускать на том серваке. Я пытался выгрузить все данные из одной таблицы, но окно терминала наебнулось и попросту не захотело выводить мне результат (не может отформатировать или хрен его знает что), как мне вывести этот результат куда-то, где я смогу гарантированного его просмотреть? файлы там создавать я не могу
Аноним 25/12/20 Птн 19:25:10 1890858216
Аноним 26/12/20 Суб 04:34:47 1891143217
>>1888482
>> Вау! Чё реально, не более трех таблиц, у реляционной модели произвольной сложности? Как на пикрил, скажем.
>да. таблица объекты(аттрибуты),
>таблица их значений,
>и таблица для связи объектов между собой.
>к этому можно свести абсолютно любую реляционную модель.
Есть где-то наглядный пример, ну или можете ли наварганить по быстрячку,
чтобы очевидно было как третью таблицу строить, ну и первую тоже.
Может если прохавать это, то можно будет сразу оптимизированные модели данных строить,
и базы данных на них уже делать, оптимизированные?
Аноним 26/12/20 Суб 17:25:18 1891515218
>>1869616 (OP)
>Есть где-то наглядный пример, ну или можете ли наварганить по быстрячку,
Я сам впервые об этом услышал, это прикольно, но, вроде, элементарно, сделай сам.
Аноним 26/12/20 Суб 23:27:24 1891894219
>>1891515
Я же писал, что я не представляю себе даже как строить эти таблицы.
Аноним 27/12/20 Вск 23:31:32 1892853220
>>1891143
> Может если прохавать это,
чтобы прохавать это нужно нормальную книжку прочитать где написано про нормализацию.

> наварганить по быстрячку,
как-то так
OBJECTS(ID, TITLE)
VALUES(OBJECT_ID,VALUE)
OBJECT_TO_OBJECT(OBJ1_ID, OBJ2_ID)

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

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

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

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

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

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

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


> Котаны, у меня есть доступ на удаленный сервак,
а доступ через что? если есть возможность пробрось порты через путти например и подключайся на своей локальной машине через pgadmin или через любую иде к котрой привык.
Аноним 28/12/20 Пнд 20:28:11 1893889221
существует ли что то типа автоподборщика команд как в ЯП?
Аноним 28/12/20 Пнд 21:02:15 1893936222
я нихера не понимаю тип данных...
вот допустим имена-это символы,возраст-числа
те char and int
а нахрена цифры(длина?) после типа?
что есть varchar?
Аноним 29/12/20 Втр 00:31:09 1894126223
>>1893936
У тебя же не может быть возраст 99999999999, вот и ограничиваешь, сколько цифр у тебя максимум в числе. Ну а для char аналогично указываешь, сколько символов в строке максимум. Char же отличается от varchar тем, что char всегда физически занимает максимум места, даже если хранишь пустую строку, а varchar столько, сколько реально в нём хранится + 1 байт для признака конца строки.
Аноним 29/12/20 Втр 00:32:50 1894128224
>>1893889
Автодополнение? БД-шная консолька в IDEA умеет такое, но не идеально. Возможно, в DataGrip тоже это есть.
Аноним 29/12/20 Втр 02:08:43 1894175225
>>1892853
>> наварганить по быстрячку,

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

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

То есть, там должна быть не просто табличка для связи объектов (по аналогии - таблиц),
но ещё и аттрибутов объектов (по аналогии - конкретных столбцов таблиц).
А если ещё строки в таблицах связаны, или конкретные значения???
Тогда эта табличка всевоможных взаимосвязей, она, должна бы быть - пиздец какой многомерной, разве не?
Аноним 29/12/20 Втр 03:33:59 1894224226
>>1893936
В зависимости от типа СУБД varchar может быть неоптимально хранить или индексировать. Когда поле небольшое и фиксированной длины с ним проще выстроить эффективную работу.
Аноним 29/12/20 Втр 11:31:57 1894412227
>>1894126
а зачем тогда подтипы int?
Аноним 29/12/20 Втр 15:32:23 1894549228
Аноны, объясните пж, когда использовать serial, когда sequence, когда auto_increment? И что такое constraint? Это все в psql
Аноним 29/12/20 Втр 16:14:13 1894596229
>>1869616 (OP)
В Постгрес если я удаляю таблицу (DROP TABLE) то мне потом отдельно надо будет удалить индексы к ней привязанные и CONSTRAINTS? Или они автоматом удалятся?
Аноним 29/12/20 Втр 16:36:45 1894620230
Аноним 29/12/20 Втр 16:38:48 1894622231
>>1894620
Однако sequence он не снимает
Аноним 29/12/20 Втр 16:45:59 1894627232
>>1894549
Автоинкремента в постгресе нет, serial сам за него всё делает. и он неявно создаёт sequence.
Аноним 29/12/20 Втр 18:20:04 1894729233
Чем мария дб отлич от майскл?
Аноним 29/12/20 Втр 18:32:33 1894744234
>>1894175
Бамп! Как строить третью таблицу?
Аноним 29/12/20 Втр 21:31:19 1894858235
>>1869616 (OP)
Пусть есть две таблицы:
|idA|A| (int, text)
|idB|B| (int, text)
и пусть есть третья таблица для связи их:
|id|idA|idB| (int, int, int)
В ней - только id'ы, числами (INT).

Как с помощью SQL, показать таблицу |A|B| (text, text) ?
Аноним 29/12/20 Втр 21:44:15 1894871236
>>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;
Аноним 29/12/20 Втр 21:54:21 1894885237
>>1894871
>>1894858
А можно как-то, без особого пердолинга, сделать так,
чтобы эта таблица была таблицей в базе,
и при вводе значений (A, B),
чтобы автоматически добавлялась запись в первые две таблицы,
и взаимосвязь этих записей - в третью таблицу?
Аноним 29/12/20 Втр 22:06:33 1894899238
А как доставать жсон-подобную инфу из sql бд? Просто вот допустим надо взять из таблицы С статус, он достается через джойн С с А. Также через джойн А и Б достается 1000 рядов допустим там заказчиков из таблицы Б через связь с заказом А.

В таком тупом примере получается, что уже надо два запроса. И что, потом их склеивать через язык программирования при формировании жсона? Джойн С с А и
Б на похуях получается бредом, там этот статус будет один на весь заказ А. Полагается использовать всякие функции по возврату жсонов и массивов в постгресе чтобы одним запросом все нормально получить?
Аноним 30/12/20 Срд 13:07:56 1895597239
>>1869616 (OP)
>pics
Анимебляди уже заябали чесслово

мимо олд
Аноним 31/12/20 Чтв 05:24:59 1896507240
>>1895597
Олды заебали уже чесслово

мимо аниме
Аноним 31/12/20 Чтв 05:26:55 1896508241
>>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, должны добавиться записи дополнительные,
чтобы там появились новые значения, которые может вводить только сам админ базы данных этого вот Пентогона.
И главное, чтобы без пердолинга!! А то я уже заибался с этими таблицами.
Я ЩА ВОЛОСЫ НА ЖОПЕ СИБЕ ПАРВУ, ПАМААААААГИТИ!!!
Аноним 31/12/20 Чтв 19:49:56 1897110242
С наступающим.
А сложно вообще создать БД с 5 таблицами новичку через workbench?
Аноним 31/12/20 Чтв 20:00:21 1897120243
Аноним 31/12/20 Чтв 23:15:36 1897356244
>>1897110
делай через консоль
Аноним 31/12/20 Чтв 23:48:21 1897379245
Аноним 01/01/21 Птн 11:32:19 1897610246
>>1897379
бд с 5 таблицами с простым наполнением-изи
Аноним 01/01/21 Птн 20:29:56 1898032247
Аноним 03/01/21 Вск 01:52:10 1899284248
>>1869616 (OP)
Как вставить 1000 строк в цикле?
Аноним 03/01/21 Вск 02:02:49 1899292249
>>1899284
-- Oracle
BEGIN
FOR I IN 1..1000 LOOP
INSERT INTO YOURTABLE (YOURCOLUMN) VALUES (YOURVALUE);
END LOOP;
END;
Аноним 03/01/21 Вск 05:17:14 1899337250
>>1899292
Бля, не пашет, тут SQLite, хуй знает как вставить 1000 ракет в эту >>1896508 таблицу Rockets...
Аноним 03/01/21 Вск 09:27:07 1899384251
>>1899337
Включаешь транзакцию и вставляешь в цикле, хуле. Потом в конце коммит.
Через insert values (), (), () лучше, конечно, но это надо руками крафтить, если не лень.
Аноним 03/01/21 Вск 09:37:52 1899386252
>>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 замыкаются,
и оно ошибки бьёт.
Аноним 03/01/21 Вск 09:45:38 1899387253
>>1899384
Я сделал проще, тупо javascript'ом в цикле, сгенерировал в консоли браузера пиздатое полотнище из кучи команд,
и в виде одного SQL-запроса, исполнил, и оно заполнилось.
Ракеты пока не полетят, не ссыте. Я их просто нацелил.

Но что если их терабайт будет, этих запростов ебучих?
Хотелось бы цикол, но ракет куча, а в сиквелайте у рекурсивных петель - синтаксис какой-то нипанятный.
Аноним 03/01/21 Вск 09:59:57 1899390254
oww.PNG 6Кб, 267x132
267x132
Аноним 03/01/21 Вск 10:16:27 1899392255
>>1899386
SELECT * FROM t2
JOIN t1 t11 ON t2.id1=t11.id
JOIN t1 t12 ON t2.id2=t12.id;
Аноним 03/01/21 Вск 10:35:20 1899401256
>>1899392
А можно как-то без звёздочки, чтобы не все поля, вылазили, а то там их просто огромная куча.
Аноним 03/01/21 Вск 10:41:49 1899410257
>>1899401
Ну так и напиши вместо звездочки, какие тебе нужны, алиасы все есть.
t2.id, t11.name, t12.name и т.д.
Аноним 03/01/21 Вск 11:05:21 1899420258
Аноним 03/01/21 Вск 23:10:15 1899986259
>>1869616 (OP)
Возможно ли связать таблицу,
с таблицей,
которой нет, в базе данных,
но которая может быть образована из других,
уже существующих, и взаимосвязанных таблиц?
Аноним 04/01/21 Пнд 01:44:24 1900063260
Аноним 04/01/21 Пнд 20:56:28 1900964261
народ посоветуйте годной литературы по ораклу именно по администрированию, как правильно разворачивать master slave роли настраивать бекапы, архивлоги и т.д.
Аноним 05/01/21 Втр 03:53:10 1901240262
cryptocurrency-[...].PNG 88Кб, 1130x549
1130x549
>>1869616 (OP)
Вкатываюсь в проектирование баз данных,
со своим SQLite Expert Professional (x86) portable.
Цель - заебенить криптобиржу.
Пока что получился пикрил, хз можно ли оптимизировать это...

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

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

А другой с перепугу обосрался, и убежал,
а перед тем ещё и, засранец, дверь говном обмазал,
и написал: АНБ + ФБР = ♥
Аноним 05/01/21 Втр 14:46:58 1901491264
>>1901240
Ты как-то непонятно изьясняешся. Есть ключи, делаешь вью с джоинами. Не понял в чём вопрос.

Аноним 05/01/21 Втр 15:21:07 1901519265
как описать float 3.14?
Аноним 05/01/21 Втр 15:22:22 1901520266
Аноним 05/01/21 Втр 15:23:43 1901522267
Аноним 05/01/21 Втр 15:24:07 1901523268
Аноним 05/01/21 Втр 15:24:50 1901524269
>>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.
Аноним 06/01/21 Срд 00:30:49 1902072270
>>1896508
С такой постановкой задачей, просто иди нахуй. В твои стену текста вчитываться никто не будет. Если хочешь чтоб тебе помогли, формализуй задачу коротко.
Аноним 06/01/21 Срд 07:48:24 1902234271
image.png 16Кб, 580x147
580x147
>>1869616 (OP)
Имеется таблица playlists с полями playlist_id, views и ещё какими-то.
Нужно выбрать все записи для плейлистов с максимальным суммарным значением views.
Написал запрос, который делает то, что мне нужно (пикрил), можно ли его упростить? Не делаю ли я в нём какой-то хуйни?
Аноним 06/01/21 Срд 10:48:53 1902283272
Анон, помоги!
Чищу mariadb, удаляю по сотне тысяч записей каждые несколько минут, база худеет, но занятое место на диске только возрастает уже который день. Почему так и как это пофиксить?
Аноним 06/01/21 Срд 11:19:42 1902305273
Аноним 06/01/21 Срд 15:39:30 1902535274
>>1902305
База подвиснет и станет недоступной? 100 гигов и 600млн записей.
Надолго?
Аноним 06/01/21 Срд 15:56:05 1902573275
>>1902535
Не знаю, я с такими объемами не сталкивался. Гугли.
Аноним 06/01/21 Срд 16:17:27 1902633276
каково применение и смысл составных ключей?
Аноним 06/01/21 Срд 16:35:52 1902678277
>>1902633
На практике почти всегда вместо них юзают суррогатный ключ (id). Значения сразу нескольких колонок сопоставляют только в сложных джойнах и селектах.
Аноним 06/01/21 Срд 16:42:01 1902699278
>>1902678
допустим есть колонка Фамилия и к ней привязать примари ки
в чем профит?
Аноним 07/01/21 Чтв 06:50:20 1903351279
Аноны, есть один сервис, с клиентами по всему миру, есть БД - Постгрес11. Я правильно понимаю, что единственный путь это мультимастер и установка нескольких серверов с БД в различных локациях и юзерами?
Планирую для начала 3 таких локации и связать их звездой при помощи Bucardo.
Аноним 07/01/21 Чтв 10:39:53 1903401280
>>1902072
То был пример с толстотой. Тащемта я уже разобрался, решение - view'ы с триггерами.
Аноним 07/01/21 Чтв 13:14:28 1903482281
>>1869616 (OP)
а манга из 1 пика есть на русском?
Аноним 07/01/21 Чтв 18:40:12 1903786282
>MariaDB [users]> select name,city,age from users where city='London' and age=43;
Empty set (0.001 sec)

почему не работает или я не в том направлении копаю?
Аноним 07/01/21 Чтв 18:44:08 1903790283
>>1903786
У тебя нет записей с city = 'London' и age = 43.
Аноним 07/01/21 Чтв 18:46:37 1903793284
>>1903790
есть.
но я наверно не верно готовлю
условие и and применимы только к одной строке?
Аноним 07/01/21 Чтв 18:51:44 1903799285
>>1903793
а блять,должно быть наличие этого в одном поле
Аноним 07/01/21 Чтв 19:19:51 1903827286

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 | huy@yahoo.com | NULL |
| 2 | Ivan | London | 19 | huy22@yahoo.com | NULL |
| 3 | Mariya | London | 19 | huy33@yahoo.com | NULL |
| 4 | Jhon | Boston | 43 | her22@yahoo.com | NULL |
| 5 | sergey | anapa | 12 | huy12@yahoo.com | NULL |
| 6 | Egor | anapa | 30 | huy67@yahoo.com | NULL |
| 7 | Gunther | Berlin | 32 | huy222@yahoo.com | NULL |
| 8 | NULL | NULL | NULL | NULL | 200.20 |
+----+---------+--------+------+------------------+---------+
8 rows in set (0.001 sec)
почему я обломался?
Аноним 07/01/21 Чтв 19:29:08 1903839287
>>1903793
> условие и and применимы только к одной строке?
Подобных ограничений нет.
>>1903799
Похоже, тебе нужен OR вместо AND.
Аноним 07/01/21 Чтв 19:32:47 1903844288
>>1903827
все,я понял ошибку
надо было заполнять через update
Аноним 07/01/21 Чтв 19:50:51 1903862289
Снимок экрана ([...].png 124Кб, 1366x768
1366x768
>>1903839
все равно не врубаюсь
Аноним 07/01/21 Чтв 19:58:07 1903868290
>>1903839
ОR сработал,вывел 2 строки где есть нужное условие
но не врубаюсь в AND
Аноним 07/01/21 Чтв 20:14:15 1903902291
>>1903868
OR выбирает записи, где выполняется хотя бы одно из условий (либо юзер из Лондона, либо ему 43 года, либо и то и то одновремено). AND - когда выполняются оба (юзер из Лондона и ему при этом 43 года)., то есть строка отсеивается, если хоть что-то не подошло.
Аноним 07/01/21 Чтв 20:19:58 1903925292
>>1903902
начало доходить,те эти данные должны быть связаны
допустим все Иваны из города Москва
а если OR он вывалит и всех иванов(из всех городов) и всех москвичей ?
Аноним 07/01/21 Чтв 20:30:32 1903945293
>>1903925
Да.
Если знаешь теорию множеств, то думай об AND как о пересечении множеств, а об OR - как об объединении.
Аноним 08/01/21 Птн 11:49:06 1904329294
SELECT КодЗаказчика, Название, Телефон
FROM Заказчики
WHERE NOT EXISTS
(SELECT*
FROM Заказы
WHERE Заказы.КодЗаказчика = Заказчики.КодЗаказчика);

Я не могу понять как это работает. Помогите
Аноним 08/01/21 Птн 14:05:08 1904455295
>>1904329
У тебя между where и not exist ничего не пропущенно?
Аноним 08/01/21 Птн 14:41:33 1904501296
Как вставить функцию в шаблонизированную строку запроса?
Поле 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"
Аноним 08/01/21 Птн 15:10:22 1904523297
>>1900964
Томас Кайт - "Oracle для профессионалов
Аноним 08/01/21 Птн 21:54:32 1905011298
Блядь, открыл первое (рейтинговое) упражнение на sql-ex и сразу охуел. Я только синтаксис прочел, а тут...

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


Помощи не прошу, просто хочу узнать может там как-то по нарастающей сложности задачки есть?
Аноним 08/01/21 Птн 22:03:10 1905031299
>>1905011
А, все, нашел что к чему. Интерфейс конечно там пиздец. Не сразу понял как выбирать сложность и номер заданий. Сначала значит надо пройти обучающий этап со всеми остальными, а потом уже если захочется рейтинговый.

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

Видимо после sql-ex'a надо литкод идти дрочить.
Аноним 09/01/21 Суб 19:20:04 1905750300
>>1904523
ну такое, слишком много пространной теории и мало практики по настройке скажем мастер и слейв баз данных
Аноним 09/01/21 Суб 19:30:34 1905761301
Я снова на связи
Как проэктировать бд с 2-3 таблицами,это к теме foreign key
Аноним 09/01/21 Суб 21:07:01 1905932302
image.png 26Кб, 986x187
986x187
>>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 - блоб
Работать с такими данными очень неудобно, но всё ещё возможно.
Аноним 09/01/21 Суб 21:08:14 1905934303
>>1905932
Разумеется, сиквенсов, триггеров, констреинтов и индексов так и остаётся 100500 штук.
Аноним 10/01/21 Вск 16:28:09 1906536304
>MariaDB [users]> insert into users2020
-> values('Arthur','Moskow','49','pizda111@gmail.com','2000','her2021');
ERROR 1136 (21S01): Column count doesn't match value count at row 1
MariaDB [users]>
что не так?
Аноним 10/01/21 Вск 16:48:06 1906563305
>>1906536
Там же написано. Если количество не совпадает, то пиши список колонок после таблицы.
Аноним 10/01/21 Вск 16:52:09 1906567306
Снимок экрана ([...].png 180Кб, 1366x768
1366x768
>>1906563
я не указал id c инкриментом и авто timestamp
Аноним 10/01/21 Вск 17:04:35 1906581307
>>1906567
Ну вот и впиши список без первой и последней колонки.
Откуда оно знает, что ты там имеешь в виду?
Аноним 10/01/21 Вск 17:06:31 1906586308
>>1906581
так уже делал
там написано
Аноним 10/01/21 Вск 17:08:29 1906588309
>>1906586
или способ без перечисления не работает?
по инструкции так же можно делать
Аноним 10/01/21 Вск 17:23:23 1906617310
>>1906588
Если значений не столько же, сколько колонок в таблице, то нужно перечислять.
Аноним 10/01/21 Вск 17:52:29 1906659311
Вы на память все помните?
Аноним 10/01/21 Вск 22:36:02 1906902312
Короче, двач, помоги. Пишу учебное приложение, тип клиника. Там у врача есть время когда он принимает.

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

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

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

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

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

Но тут вопрос, как сделать 2 перерыва? Вот ж блять, ребят подскажите)))
Аноним 10/01/21 Вск 22:48:44 1906908313
>>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 перерывов в день.
Аноним 10/01/21 Вск 22:52:52 1906912314
>>1906908
Бля, а не плохо. А можно ли запилить констрейнт чтобы нельзя было пересекающиеся записи делать?
Аноним 10/01/21 Вск 23:19:40 1906928315
>>1906912
Можно написать триггер с проверкой, триггер будет перед инсертом/апдейтом селектить существующие записи и проверять. Либо вообще вынести проверку на уровень самого приложения.
Аноним 11/01/21 Пнд 09:32:57 1907058316
>>1906912
Можно запись делать через merge.
Аноним 11/01/21 Пнд 10:30:45 1907072317
>>1894729
ну, в mariadb есть query cache.
и в целом, они более повернуты к людям.
Аноним 11/01/21 Пнд 11:11:16 1907095318
Аноним 11/01/21 Пнд 11:46:19 1907111319
Поясните плес, почему SQL настолько уёбищный язык? Пока что это все
Аноним 11/01/21 Пнд 11:49:04 1907112320
>>1907111
а что не так?
есть предложения?
Аноним 11/01/21 Пнд 11:59:19 1907119321
>>1907112
Уебанский синтаксис, а именно структура запросов, произвол в пихании куда попало ключевых слов лишь бы это было похоже на английский и все такое.
Аноним 11/01/21 Пнд 12:00:09 1907120322
Аноним 11/01/21 Пнд 12:04:28 1907122323
>>1907120
как в нормальных языках. например, если есть
WHERE xxx IN ( arg1, arg2,...)
то, блядь и делать
WHERE xxx BEETWEN ( arg1, arg2)
а не хуйню
WHERE xxx BEETWEN arg1 AND arg2
как оно сделано
Мало того, что меняется сигнатура по сути одной семантики - ограничения области, так еще и зачем-то вхуячено слово, которое и так уже используется как логическая операция в этом же, блять, языке, не говоря уже обо всех других
То же самое еще в куче мест, например FROM-INTO и т.д.
Аноним 11/01/21 Пнд 12:15:24 1907129324
>>1907119
>лишь бы это было похоже на английский
В этом и была цель при разработке sql - чтобы он был максимально похож на естественный язык и на нём могли писать запросы простые людишки. Собственно, с этой задачей он более-менее справился.
Аноним 11/01/21 Пнд 12:17:22 1907133325
>>1907122
Ну, наверное, between может быть только между двумя значениями, а в кортеже их может быть больше двух, что может вносить путаницу.
Аноним 11/01/21 Пнд 12:23:00 1907141326
>>1907133
Конечно, может. Но гораздо большую путаницу вносит как раз разный тип синтаксиса для по сути одного и того же.
>>1907129
Естественный язык тем и плох для разработки ПО, что он сравнительно не строгий, и в нем все пихается плюс минус рандомно, лишь бы тупая нейросеть в кожаном мешке могла это понять, а если что переспросить.
Плохо сделали, ящитаю.
Аноним 11/01/21 Пнд 12:51:25 1907185327
>>1907141
>разный тип синтаксиса для по сути одного и того же
Between - это бинарный оператор, а у IN операндов может быть больше (или меньше) двух, не помню как это одним термином называется. Это если с точки зрения программиста смотреть. С точки зрения нормиса всё ещё логичней - как в английском, так и в sql.
>он сравнительно не строгий
Так и есть. Но именно это и нужно было - чтобы "пользователи ПК" не переучивались мыслить как кодеры, а могли использовать знание своего языка для написания запросов (не знаю, насколько это в реальности нужно было, просто пару раз читал такое обоснование). То, что это стало стандартом - ну, так получилось, теперь мы с этим живём. Меня, например, конкретно синтаксис не очень сильно беспокоит в sql.
Аноним 11/01/21 Пнд 13:02:29 1907194328
>>1907185
Это называется арностью операции. И вот как раз вызов операции в любом ЯП должен быть, если ЯП не уёбищный, организован типовым, унифицированным, образом.
>Так и есть. Но именно
Ну, какова бы история не была этого вопроса, суть не меняется: SQL как язык - уёбок. И все им пользуются только потому что он привычен, да и вообще маленький, типа, можно и выучить всё это нагромождение тупой хуйни наизусть, игнорирую то что это куча завязанных в узел костылей. Я что-то особо не знаю юзеров SQL, которые по совместительству не программисты на более божеских языках, и по сути поэтому можно заключить, что идея обосралась на корню.
Аноним 11/01/21 Пнд 13:06:13 1907198329
>>1907122
> как в нормальных языках
Скажи это дедам полвека назад.
SQL - это легаси, с которым приходится жить. Давно придумали, все смирились с синтаксисом, написано дохуя кода и литературы с использованием SQL, это всё хрен выкинешь. Да и ради более модного синтаксиса никто и подавно этого делать не будет.
Аноним 11/01/21 Пнд 13:14:04 1907211330
>>1907194
Sql - не ЯП же, значит можно.
>все им пользуются только потому что он привычен
Ага, а привычен потому, что все его учат. А учат, потому что привычен...
>Я что-то особо не знаю юзеров SQL, которые по совместительству не программисты
У нас есть аптечники, которые с БД работают на уровне простых select-insert-update.
Аноним 11/01/21 Пнд 13:23:28 1907223331
>>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 на флешку поставить, охуенно же опенсорц, к тому же меня ещё и прёт чёт-то ото всех этих баз данных.
Аноним 11/01/21 Пнд 13:27:34 1907229332
>>1907211
>Sql - не ЯП
С чего? то что он не тьюринг-полный, не значит что он не ЯП. По сути любой интерфейс между взаимодействующими сущностями это небольшой ЯП.
>Ага, а привычен потому, что все его учат. А учат, потому что привычен...
Нет, просто тонны легаси-дерьма вряд ли можно уже отвергнуть, к сожалению. Схожая ситуация есть с некоторыми аппаратными архитектурами, которые уёбищные, но слишком уж распространены.
>работают на уровне простых select-insert-update.
ради этих трех операций можно и аптечнику запомнить нормальный унифицированный синтаксис вызова. В итоге вышло, что ради того, чтоб одному аптечнику удобно было пользоваться 3% языка, 999 программистов мучаются с 100% тупого синтаксиса
Аноним 11/01/21 Пнд 13:37:42 1907233333
>>1907223
> Если так, то почему бы сразу не писать в нормальной, оптимальной, минимальной и удобной форме,
вместо того чтобы связывать эти таблицы в ебические сети из нафиг не нужных сущностей, которые можно описать одной лишь табличкой - пропроще?
Сначала делаешь все в "минимальной и удобной форме". Затем понадобятся проверки, что в этих таблицах поверх таблиц записи содержат только указанные столбцы и только указанного типа. Для этого создаёшь ещё таблицы со схемой, пишешь много сложных триггеров и понимаешь, что заново изобрел таблицы с ебическими сетями сущностей, но лишним слоем абстракции.
Аноним 11/01/21 Пнд 13:50:28 1907243334
>>1907223
>А пока, на SQLite, я тут, просто заебенил - простенький ToDo-list
Такую ёбу лучше на JavaScript сделать, в виде одного JSON-объекта, плюс LocalStorage, так будет ещё и доступнее, в браузере.
Там же нет множества таблиц связанных, просто одна табличка, которая может быть в один объект записана, и ещё один view, который может быть веб-мордой для объекта.
Аноним 11/01/21 Пнд 13:58:46 1907249335
>>1907233
Мне почему-то кажется, что критерием оптимизации
самой вот реляционной модели данных,
является именно дублирование данных, в различных таблицах.
Ведь, в пределе, как я понимаю,
всё можно свести к банальным, взаимосвязанным между собой,
спискам уникальных элементов - таблиц с одним полем,
группируя их в таблицы по общему признаку.
Ну а дальше уже, просто таблицы с числовыми ссылками на эти вот уникальные элементы списков.
Каждое новое поле для таблицы с большим числом столбцов - это лишь новая таблица, свазанная с предыдущей - 1 к 1.
И так, короче, куча таблиц получается, в каждой из которых по одному полю.
В основном, это таблицы с цифрами, которые не занимают дофига памяти,
а вот уникальные элементы, они просто в таблицах-списках, один раз записаны, и не дублируются нигде.

Так, мне видится, оптимизированная модель данных,
но всё-же, ебическая куча таблиц - это не четыре таблицы, и не одна. Хотелось бы чё-то более универсальное, оптимальное, и конечно же - минимальное.
Чтобы один лишь раз, нужные данные, в базу данных, забить, сделать их ридонли, как-то защитить, и не ебать уже мозг излишним их дублированием.
Аноним 11/01/21 Пнд 14:32:33 1907295336
>>1907249
Не всё в реляционной модели сводится к оптимизации. Например, существование констреинтов не уменьшает дулбирование, но из этого не следует, что оно не нужно. То же самое с разделением сущностей и контролем типов на уровне СУБД.
Аноним 11/01/21 Пнд 15:03:43 1907360337
>>1907249
Я мимопроходил и понимаю, что ты шизик, но желаю тебе счастливого Cartesian Explosion при джойне твоего оптимизированного говна.

Ну и вообще, твоё видение оптимизации странноватое. Что-то уровня демосценного байтоёбства. На деле важнее перфоманс, поэтому в реальных проектах часто прибегают к денормализации схемы БД.
Аноним 11/01/21 Пнд 19:15:22 1907635338
>>1907360
На деле, всё просто. Вот есть схема данных, таблицы и их взаимосвязи. Если её с нуля строить, всё-как бы норм, пара таблиц, и пара связей.
Но если наславать и усложнять всю эту хуйню, появляется хуева куча таблиц и куча связей, целая сеть ебучая, как сеть петри и нейросеть, в которой уже хуй разберёшься, без аккуратног сдвигания окошек, которые уже не лезут в окно схемы данных, и без отслеживания связей между этими вот - таблицами ебучими.
Нахуй нужно столько таблиц, и связей между ними?
МОЖНО КАК-ТО ПОПРОЩЕ?
Вот основной вопрос, который задаёшь себе, при проектировании сложной модели данных.
Следующий вопрос... А что насчет оптимизации? И/или нормализации? В нормализацию я не могу, ибо я не изучал все эти отношения и реляционную алгебру между ними,
у меня тупо таблички и связи, здесь.
И вот число табличек и число связей, надо бы как-то уменьшить.
И внезапно, анон, говорит, что можно описать любую реляционную модель тремя таблицами (или четырьмя, или даже одной, той, god_table),
но ибаццо с такими данными через хуеву кучу триггеров, мягко сказать, не нормально. Значит база нихуя не нормализована, данные не имеют нормальную форму.
Но я же, узрел, в трех таблицах (ну или четырех, блядь, которые так и не гуглятся), результат нормализации ЛЮБОЙ СХЕМЫ ДАННЫХ, и как-бы даже УНИВЕРСАЛЬНУЮ МОДЕЛЬ ДАННЫХ, в которой можно уместить ЛЮБУЮ МОДЕЛЬ.
Отсюда и понос этот весь.
Аноним 11/01/21 Пнд 19:24:41 1907662339
>>1907360
>На деле важнее перфоманс, поэтому в реальных проектах часто прибегают к денормализации схемы БД.
Я так понимаю. денормализация ведёт к дублированию данных, или просто растёт сложность модели данных, в смысле число таблиц и свзей между ними?
Потому что, как я понял, из примера анона >>1905932
с его универальной одной, общей, god_table,
одна таблица, получается, это хорошо и прекрасно,
но внутри неё данные - дублируются пиздец как.
И если снизить дублирование данных,
придётся делать таблицы-списки с уникальными элементами,
и на них уже ссылаться из других таблиц,
а значит растёт число таблиц и число связей между ними,
и усложняется схема данных - то есть растёт сложность самой этой вот - реляционной модели данных.
Хотя да, растёт перформанс, ведь при записи/обновлении, достаточно обновить одно значение, а не делать кучу INSERT и UPDATE, ну а чтение достаточно закешировать, да и всё на этом.
Аноним 12/01/21 Втр 09:48:05 1908077340
>>1907662
>>1907635
Без негатива, но я даже не вижу, что тут нам можно обсудить. Ты тратишь время на какую-то эзотерику уровня Brainfuck. Просто рекомендую этого не делать.

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

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

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

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

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

>Модель данных -- это очень важная часть решения задачи,
>она твой помощник и она фундамент твоей работы.
>Ты пытаешься от неё отказаться и называешь это какой-то оптимизацией,
>но фактически это эзотерический эксперимент,
>и оптимизирует он что-то в том же смысле, в каком коронавирус оптимизирует население страны.
нет, нет, тут не совсем так ты меня понял. Я пытался выбрать именно оптимальную структуру БД, и понять как строить - на базе неё любые модели данных.
Хотя, впрочем, я описал уже выше, в этом посте, как, к этому, я подошёл.
Аноним 14/01/21 Чтв 09:50:49 1909694342
wtvr.png 719Кб, 817x2781
817x2781
>>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. Это эзотерика и брейнфак. Реляционки такое делать позволяют, реляционная теория -- нет.

> что показалось мне весьма охуенным, ведь если любую реляционную модель,
можно представить в некоей универсальной форме,
Ну, думаю, я тебе немного проиллюстрировал, что ты не особо понимаешь, какие именно проблемы реляционные СУБД решают и думаешь вообще не в том направлении, рискуя проебать кучу времени на хуйню и стать чуваком с пика, чего я тебе не желаю.
Аноним 15/01/21 Птн 01:49:17 1910384343
image.png 15Кб, 782x203
782x203
Сап!
Супер-быстрый low-iq вопрос по SQL:
База данных - в формате, как выделено зелёным на скрине.
Как написать запрос, чтобы результат был как выделено синим на скрине?
Аноним 15/01/21 Птн 02:04:41 1910396344
>>1910384
Это не получится простым sql запросом. Надо какие-то анальные расширения или в коде собирать.
Аноним 15/01/21 Птн 07:38:16 1910449345
>>1910384
Использование одной таблице несколько раз в одном запросе с внутренним соединением?
Аноним 15/01/21 Птн 09:02:28 1910465346
>>1910449
Хех, я предполагал что-то такое, но без понятия, как это сделать.
Мог бы кто-нибудь написать запрос для примера со скрина? А далее я смогу перенести на свою задачку.
Аноним 15/01/21 Птн 09:57:57 1910478347
sql.png 19Кб, 1321x659
1321x659
>>1910465
Сделала на коленке.
Последний групп и лимит костыль чтобы показывало по одной записи.
Можно сделать красивше, но это уже сам додумай.
Аноним 15/01/21 Птн 10:37:56 1910488348
>>1910478
>Сделала на коленке
умница! теперь выкладывай сисечки.
Аноним 15/01/21 Птн 10:47:50 1910489349
>>1910488
Опечатался
Могу тебе только хуй за щеку скинуть
Аноним 15/01/21 Птн 11:38:19 1910514350
>>1910478
Спасибо!
Только с "далее я смогу перенести на свою задачку" я погорячился, походу, лол (:
Аноним 15/01/21 Птн 11:58:05 1910522351
>>1910489
себе скинь, педрила криворукий
Аноним 15/01/21 Птн 19:03:58 1910951352
>>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
Аноним 15/01/21 Птн 22:36:18 1911261353
Сап, sqlач.
Кроме sql-ex, какие есть сайты с задачками по sql?
Менее припизднутые, чем на sql-ex.
Аноним 15/01/21 Птн 22:55:59 1911277354
>>1909694
Мол, в 35 лет чел знает все понемногу и нихуя на уровне профессионала?
Аноним 15/01/21 Птн 23:40:05 1911321355
>>1911277
В смысле, что он просто отбитый.
Аноним 16/01/21 Суб 09:04:59 1911497356
>>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
Аноним 16/01/21 Суб 10:24:49 1911519357
>>1911261
Sql academy
Но задачки не оч сложные
Аноним 16/01/21 Суб 11:29:50 1911537358
>>1909694
>Графовая модель, например. На реляционки она натягивается примерно как сова на глобус, сейчас для этого обычно используют что-то вроде ArangoDB. Там есть ACID и нет SQL, кстати.

https://ru.wikipedia.org/wiki/Графовая_база_данных#Описание
>Для задач с естественной графовой структурой данных графовые СУБД могут существенно превосходить реляционные по производительности, а также иметь преимущества в наглядности представления и простоте внесения изменений в схему базы данных.

Но там не сказано, что графовая модель несовместима с реляционной. Это так, или всё-же можно преобразовать любую графовую модель в реляционную, и реляционная модель достаточно универсальна, чтобы представить ею - абсолютно любую модель, в том числе и графовую?
Пусть сложно, пусть не очень наглядно, но всё же...
Аноним 16/01/21 Суб 11:34:48 1911539359
>>1911537
Что-то вроде одной таблицы связей вершин графа, с указанием там направления этих связей и силы этих связей может поместиться в реляционную модель, я думаю.
Но если так мозги описывать, например, с их 100 миллардами нейронов, и по 10000 связей по каждому ихнему дендриту их, каждый-с-каждым, то пиздец получается какой-то,
пиздатая таблица многие-ко-многим, c 1000 триллионов строчек, и ещё и весовые коэффициенты надо указать, в отдельном поле у неё.
Охуенный граф.
Аноним 16/01/21 Суб 11:36:05 1911541360
>>1911539
Если он ещё и двунаправленный, надо будет ещё и направление связей указать, это ещё одно поле с 1000 триллионами значений.
Аноним 16/01/21 Суб 19:09:38 1912062361
>>1911537
> или всё-же можно преобразовать любую графовую модель в реляционную
Можно вообще любое говно преобразовать в типа-реляционное, это выше обсуждалось. Это будет работать, но это будет неправильно, потому что ты потеряешь свои концептуальные и логические модели данных, оставив только физическую и используя СУБД как серверный Excel для хакеров.

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

Погугли, что ли, курсачи какие-нибудь по проектированию БД. Там должны быть расписаны шаблонно все этапы. Если ты не совсем ещё потерян, то поймёшь, что у тебя не должна God Table получиться после концептуального и логического этапов проектирования.
Аноним 17/01/21 Вск 22:18:21 1913481362
Аноним 18/01/21 Пнд 00:05:12 1913624363
>>1869616 (OP)
Согласно принципам архитектуры Фон-Неймана,
в частности, согласно "принципу однородности памяти",
команды (инструкции) и ДАННЫЕ,
хранятся в одной и той же памяти.

>Команды и ДАННЫЕ хранятся в одной и той же памяти и внешне в памяти неразличимы.
>Распознать их можно только по способу использования;
>то есть одно и то же значение в ячейке памяти может использоваться и КАК ДАННЫЕ,
>и КАК КОМАНДА, и КАК АДРЕС в зависимости лишь ОТ СПОСОБА ОБРАЩЕНИЯ К НЕМУ.
>Это позволяет производить над командами те же операции, что и над числами,
>и, соответственно, открывает ряд возможностей.
>Так, циклически изменяя адресную часть команды,
>можно обеспечить обращение к последовательным элементам массива ДАННЫХ.

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

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

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

Это походит на что-то вроде кэширования... Но нет, это не совсем то.
Вопрос скорее в том, возможно ли наславивать неограниченное количество закэшированных данных, в базе данных, так,
чтобы производить минимум вычислений тьюринг-полным устройством?
Если возможно, то возможно ли, после всего этого, произвести оптимизацию и нормализацию данных так, чтобы ужать базу данных с этими вот закэшированными BLOB'ами, в минимальные размеры, и чтобы она была оптимальной эта база данных,
а не раздута до ебических размеров?
Что-то вроде универсальной логической схемы для конкретного приложения, имеющей минимальный размер. Что-то вроде скомпилированной программы, но внутри базы данных.
Аноним 18/01/21 Пнд 00:21:26 1913641365
>>1913624
Если язык не является тьюринг-полным, то нельзя, какие абстракции в рамках языка ни строй, абстракции всегда ещё более ограниченные, чем сам язык наверняка это как-то связано с теоремой Гёделя о неполноте, но мне как-то пох.
Впрочем, пишут, что SQL тьюринг-полный, если юзать рекурсивные запросы.
> расширение
Расширениями можно хоть пустое множество Ø сделать тьюринг-полным. Так можно прийти к хранению исходного кода хоть на питоне в БД и запуске его в питоньем интерпретаторе с помощью этого расширения.
Аноним 18/01/21 Пнд 00:25:05 1913643366
>>1913638
Ясен хуй, что если результаты вычисления могут быть разбиты на части атомарные, которые уже есть в базе данных, то проще эти результаты вычисления не писать BLOB-ами ебическими,
а вписать внутрь реляционной БД - в виде таблиц, и записей в таблицы, по которым легко и просто найти результат,
вместо того, чтобы его вычислять.
И как-бы по частоте использования, уже, обращаться к этим записям, и отсортировать их внутри таблиц, и взаимосвязать заебато.
Аноним 18/01/21 Пнд 00:33:02 1913645367
>>1913641

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

Так вопрос был в том, будет ли вся эта ёба,
более оптимальной по размеру,
из-за её реляционости универсальной,
которая может быть оптимизирована и нормализирована.
Или же не будет?
Всё-таки, скомпилированные программы, имеют малый размер, и являют собой ничто иное как ДАННЫЕ на жестком диске/флешке/SSD, а вот уже СПОСОБ ИСПОЛЬЗОВАНИЯ этих данных,
при запуске программ этих вот, скомпилированных,
делает из них ПРОГРАММЫ, а не просто ДАННЫЕ
(которые, как я подозреваю, могут быть и в базе ДАННЫХ,
и не просто EXE-шники, BLOB'ами, блядь,
а в реляционных базах данных,
то есть, в виде реляционных данных, какой-либо реляционной модели программы, и тупо - в виде таблиц и связей между ними).
Ясное дело, что в виде таблицы можно любой HEX-код расписать,
как в HEX-редакторах он и выводится, таблицей.
Но такой способ хранения - не очень оптимальный, как по мне.
В общем, взглянул так, на всё это, и думаю, быть может удсться найти что-то прорывное, и невъебенное здесь.
Аноним 18/01/21 Пнд 00:49:11 1913655368
>>1913645
> будет ли вся эта ёба, более оптимальной по размеру, из-за её реляционости универсальной, которая может быть оптимизирована и нормализирована.
Не будет. Нормализация - это не способ абсолютного сжатия данных до возможного минимума. Даже архиватор порой справится лучше.
> СПОСОБ ИСПОЛЬЗОВАНИЯ этих данных, при запуске программ этих вот, скомпилированных, делает из них ПРОГРАММЫ, а не просто ДАННЫЕ
Да, и ничего сверх этого здесь не выдумать. SQL-запросы - это просто один из способов использования данных, и даже если суметь заставить СУБД читать "команды" из таблицы и выполнять их, это концептуально ничем не отличается от того же процессора, выполняющего команды над данными в ОЗУ.
Аноним 18/01/21 Пнд 01:17:39 1913678369
>>1913655
>Нормализация - это не способ абсолютного сжатия данных до возможного минимума.
>Даже архиватор порой справится лучше.
Кстати, я уже думал над этим, то есть над сжатием данных, с помощью "реляционной модели данных",
и думал, в контексте "принципов построения Кодов Хаффмана": https://ru.wikipedia.org/wiki/Код_Хаффмана
"Код Хаффмана", позволяет сжимать данные, оптимально кодируя их,
а именно - представляя символы различными, короткими кодами, в зависимости от частотности использования их,
причём так, чтобы символы встречающиеся наиболее часто,
кодировались более короткими кодами, которые в итоге - встречаются чаще более длинных кодов.

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

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

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

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

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

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

Первый exec отрабатывет внутри if,а второй будто он идёт после, внезависимости от условия if. Что не так?


Аноним 18/01/21 Пнд 03:09:49 1913775371
>>1913774
А всё, успех. BEGIN...END
Аноним 18/01/21 Пнд 06:09:36 1913815372
Зачем указывать foreign key при создании таблицы? Есть преимущество от того что ключ забит жёстко, а не просто логическая связь?
Аноним 18/01/21 Пнд 08:33:52 1913851373
>обновился mysql
>Version 8.0.23 has no release notes, or they have not been published because the product version has not been released.

Ахуеть.
Ну готовьте анус для уязвимости века!
Аноним 18/01/21 Пнд 08:35:31 1913853374
>>1913815
Эхо старой войны между программистами и дба.
В принципе все промышленное IT - это борьба с долбоебизом и случайными ошибкам.
В программе Laba1.pas или научном исследовании, где из долбоебов один ты - можешь не создавать.
Аноним 18/01/21 Пнд 10:02:10 1913886375
>>1913678
>>1913815
Ты всё же потерянный и несёшь прямо полную хуетень.
Аноним 18/01/21 Пнд 11:07:02 1913918376
>>1913815
Например, чтобы ON DELETE CASCADE работал.
Аноним 21/01/21 Чтв 10:22:29 1916951377
Сап, котятки. Поясните, насколько плохо пользоваться такими штуками как констрейнты и не дублировать их в коде?

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

Ну или там занесение сохранёнок через миграции? Где-то у вас в продуктах так делают, или на петухоне всё пишут связанное с бизнесой, а максимальный констрейнт это unique?
Аноним 21/01/21 Чтв 10:44:41 1916972378
>>1916951
Да, максимум проверок в БД - это NOT NULL/UNIQUE/REFERENCES. Хз насчёт общепринятых причин считать логику в БД чем-то плохим, но как минимум такое неудобно дебажить + проверки в коде всегда можно по-быстрому переписать без новых скриптов миграции.
Аноним 21/01/21 Чтв 13:07:13 1917036379
igor-bogdanov-s[...].jpg 28Кб, 500x500
500x500
Сосоны, если я решил 50 задач полностью сам включая 3 и 4 уровень на скл-ех в разделе обучения, можно начинать поиски позиции джуна аналитика с предположением, что я достаточно знаю мат стат и теорвер?
Аноним 21/01/21 Чтв 14:07:42 1917083380
Аноним 21/01/21 Чтв 15:35:58 1917153381
как назначить сущ колонке с эиейлами уникальный ключ?
Аноним 21/01/21 Чтв 15:41:00 1917158382
Аноним 21/01/21 Чтв 16:29:01 1917213383
>>1916972
Почему дебажить неудобно? Тестики написал, тестики выполняются.

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

Я предпочитаю иметь имя таблицы которая меняется в моей миграции. По имени найти можно. Да и тесты поменялись, по тестам видны требования.
Аноним 21/01/21 Чтв 16:37:55 1917220384
>>1917213
Как через дебаггер подключиться к базе? Никак.
Тестики укажут, что есть ошибка, но не объяснят, в каком месте она возникает. Если у тебя большая и сложная бизнес-логики, где что-то сеттится в разных местах и в зависимости от условий, что-то копируется, что-то не копируется, без дебаггера охуеешь её искать.
Аноним 21/01/21 Чтв 17:21:35 1917257385
>>1917220

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

Ща бы код ООП дебажить покрытый юнит и фичер тестами
Аноним 21/01/21 Чтв 17:30:36 1917264386
>>1917257
Посмотрю я на этот TDD в проекте на 500К строк с постоянно горящими сроками.
Аноним 21/01/21 Чтв 17:34:28 1917270387
>>1917264

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

А время дебагинга бывает очень разное, его невозможно спрогнозировать и чаще всего заэстимейтить тоже.
Аноним 21/01/21 Чтв 17:41:49 1917280388
>>1917270
> Оно прогнозируемо.
Конечно, всего-то 100500 человеко-дней на полное покрытие всех возможных кейсов.
Аноним 21/01/21 Чтв 17:55:17 1917300389
>>1917280
Та ты преувеличиваешь, пишут на ТДД и заебись живут. Почитай Мартина, Мартин дело говорит.

Аноним 21/01/21 Чтв 18:16:28 1917322390
>>1917300
Ну, у нас тесты пишут только для определённых случаев, в целом код ими мало покрыт, но на написание времени уходит много. Да и даже когда они падают, причину всё равно приходится искать дебагом, ибо что-то прийти может из непокрытого кода из метода на 200 строчек (лол).
Мартина в закладки добавляю.
Аноним 21/01/21 Чтв 20:28:05 1917467391
>>1916951
Смотри, расклад такой. Сохранёнки не юзай. Сохраненки говно.

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

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

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

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

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

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

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

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

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

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

Ещё, проекты очень большие это хоть и правда жизни, но это плохо. Надо разбивать на маленькие.
Аноним 22/01/21 Птн 22:17:22 1918441392
>>1917036
Да x2. Сам примерно так и нашёл.
Аноним 23/01/21 Суб 04:49:07 1918866393
DsMrnDLWoAAYA2V.png 123Кб, 309x407
309x407
Аноны когда нужно заниматься поддержкой индексов? Вот допустим есть таблица с внекластерным индексом, новые значение поступают регулярно, если удаляются данные, то всегда только самые старые, обновлений нет.
Нужно ли при таком раскладе обслуживать индексы? Насколько я понимаю переиндексацию надо делать если данные обновляются/удаляются за промежуточный период, если с краёв накидывют, то и так работает. или я не прав?
Аноним 24/01/21 Вск 10:54:11 1919787394
Кто-нибудь может помочь с простой для меня неподъемной задачей аля создать мини-базу данных в SQL? Я неебу как это работает, у меня не работает ничего, я проебала всю теорию и все практики, а нужно сделать экзамен

Хелп плис :(
Аноним 24/01/21 Вск 10:59:39 1919796395
Аноним 24/01/21 Вск 11:57:11 1919842396
Аноним 24/01/21 Вск 12:04:50 1919845397
>>1919796
А collation? Как же длину хуев сравнивать?
Аноним 24/01/21 Вск 18:44:34 1920171398
в вебе примари кей кому обычно назначают кроме id?
эмейлу,фамилии?
Аноним 24/01/21 Вск 18:58:35 1920183399
Сап, двач. Плез подскажи, какая в sqlite3 есть возможность сравнить 2 даты и получить разницу в минутах(секундах) при запросе?
Аноним 24/01/21 Вск 19:03:04 1920189400
>>1920183
В нем нет дат. Хранишь юникс таймштампы и считаешь разницу в секундах.
Аноним 24/01/21 Вск 19:05:10 1920192401
>>1920171
Обычно даётся id-шнику.

Делать email PK не очень хорошо по следующим причинам.
1) Сравнение с ID это очень частое сравнение, сравнивать строки дольше чем циферки
2) Связывать таблицу с другими по эмайлу это лишняя морока, хранишь больше данных и дольше джойны
3) Заёбы с апдейтом. Допустим ты захочешь поменять ID. Тебе придётся делать сложные апдейты(связанные таблицы). Вообще изменять ID не советуют. Даже если твой софт не позволяет менять email, фамилию-то можно поменять? Тянучки замуж выходят так-то.
Аноним 24/01/21 Вск 19:08:04 1920196402
>>1920192
а уник лучше дать мылу?
Аноним 24/01/21 Вск 19:53:28 1920240403
>>1920196

Ну если у тебя по логике он должен быть уникальным, то да.
Аноним 24/01/21 Вск 20:06:03 1920256404
>>1920240
еще вопрос.
я щас колупаюсь с внешними ключами
как лучше назвать колонку из табл сообщений с внешним ключом,если он ссылается на id пользователей? также ?
Аноним 24/01/21 Вск 20:26:16 1920286405
>>1920189
У меня дата, вернее время в строке hh:ii
Аноним 24/01/21 Вск 20:27:47 1920287406
почему не удаляются таблицы?
Аноним 24/01/21 Вск 20:32:26 1920290407
Аноним 24/01/21 Вск 20:33:36 1920291408
>>1920256

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

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

users
- id
- name
- email
- img

и

comments
- id
- thread_id
- user_id

То обычно так называют.
Аноним 24/01/21 Вск 20:39:46 1920295409
>>1920286

Псс, можно не отвечать. Решил в пизду, запрошу оба поля из SQL и в php вычту разницу.
Аноним 24/01/21 Вск 23:52:53 1920464410
>>1869616 (OP)
> - Разбираемся, почему PostgreSQL - не Oracle

А поясните популярно почему PostgreSQL круче MySQL и чем Oracle круче обоих
Аноним 25/01/21 Пнд 00:10:28 1920508411
>>1920464
В оракле есть MERGE, и больше нигде его нет. Это всё, что нужно знать.
Аноним 25/01/21 Пнд 09:32:00 1920795412
>>1920464
На оракле можно разориться
Аноним 25/01/21 Пнд 10:35:10 1920835413
>>1920508
смысли нигде нет? Там какой-то особенный merge?
Аноним 25/01/21 Пнд 10:39:12 1920841414
>>1920835
И мускле и постгресе только убогий insert ... on duplicate key update/on conflict do update.
Аноним 25/01/21 Пнд 11:02:18 1920874415
>>1920841
В mssql есть merge. Гугл говорит в постгресе тоже.
Аноним 25/01/21 Пнд 11:18:15 1920890416