SQL для чайников

Процессоры

SQL для чайников. Реляционные БД. Типы данных

Всем доброго дня, пикабушники и пикабушницы.

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

Оставлю это здесь, может кому-то пригодится.

Для начала, надо разобрать, что же такое SQL, а так же, где, как и зачем применяется.

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

Считаю справедливым, что нужно дать определение РБД:

Реляционная база данных — это тело связанной информации, сохраняемой в двухмерных таблицах.

Напоминает адресную или телефонную книгу, в которой есть зависимости.

SQL для чайников. Реляционные БД. Типы данных SQL, Для чайников, База данных, Длиннопост

Такая адресная книга называется двухмерной (строка и столбец) таблицей информации.

Еще проще говоря — у нас есть Петров Иван, и ему будет соответствовать номер телефона и адрес — они «привязаны» к нему. Это позволяет хранить информацию систематизировано, в порядке.

В этом весь смысл РБД — хранить информацию так, чтобы ее можно было легко и правильно получить. Много таблиц с зависимостями.

БД обычно не состоят из одной таблицы, поэтому, мы добавим еще одну:

Ничего не изменилось: так же, набор атрибутов у определенных «лиц».

Если мы захотим найти всю информацию по этим трем людям, мы получим следующее:

Вся информация в строке привязана к какому-то одному атрибуту — он и будет называться Первичным Ключом. Он — основа вашей системы записи в файл; и когда вы хотите найти определенную строку в таблице, вы ссылаетесь к этому первичному ключу.

Кроме того, первичные ключи гарантируют, что ваши данные имеют определенную целостность.

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

Строковые типы:

SQL для чайников. Реляционные БД. Типы данных SQL, Для чайников, База данных, Длиннопост

Типы с плавающей точкой (дробные числа) и целые числа:

SQL для чайников. Реляционные БД. Типы данных SQL, Для чайников, База данных, Длиннопост

Целые числа, дата и время:

SQL для чайников. Реляционные БД. Типы данных SQL, Для чайников, База данных, Длиннопост

Тут стоит заметить, что в разных БД могут быть разные типы данных, но базовые типы — остаются.

Вернемся к определению SQL.

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

P.S.: если все же полезная инфа, могу написать еще парочку статей о простых запросах Select с условиями Where. Напишите в комментарии.

Дубликаты не найдены

Лига программистов

262 поста 4.6K подписчика

Правила сообщества

Правило 0. begin

Правило 1. Пост не относящийся к программированию или, хотя бы, к IT-индустрии — исключается из сообщества.

Правило 2. При публиковании поста ставим корректные теги, передающие смысл публикации.

Правило 3. end.

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

Может они из других баз пришли, не таких классических?)

Они пришли из «хуяк-хуяк и в продакшн». Я столько таких долбоёбов повидал, что даже немножко страшно.

хм, в SAP повсеместно используются буквенно-числовые индексы.

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

но ведь сап сам по себе так построен. Хоть убейся, но индексы будут с буквами, причем в стандартных объектах. Ну во так у него заложено. Зато он быстрый, но очень дорогой (если говорить о BW+HANA)

Я видел, когда ключевое поле в таблице назначали по 7 char-полям.

Ну это уже реальное извращение.

> Вся информация в строке привязана к какому-то одному атрибуту — он и будет называться Первичным Ключом.

Если б я не знал что такое первичный ключ, то ничего бы не понял.

Вспоминаю золотые студенческие годы. Сдавали мы свежепридуманный ГосЭкзамен (не помню, как точно он назывался в 2002-м), специальность — Прикладная Математика (математика+программирование). Выпало мне сдавать вопрос «SQL» преподу от компьютеров сильно далекому, но в математике мощному. Никогда не забуду его слова и детям буду перессказывать. Он сказал, «я в этих ваших технологиях не умею, но ты, vaduha, если мне расскажешь так, чтобы я понял — поставлю зачет, не расскажешь — значит сам не знаешь нихера». Получил в тот день и зачет и мудрость.

ты на собеседование хоть раз ходил?

Если кто-то действительно хочет изучить SQL, рекомендую начать не с постов на пикабу, а с вебинара MS 10774 Гурьянова и Самородова. Курс примерно 2012 года, но всё актуально и на сегодняшний день.

Практиковаться после курсов можно тут: https://www.sql-ex.ru/

Плюс на sql.ru есть неплохие статьи, когда уже более конкретно человек определится. То что в посте вообще смысла не несет.

Если бы я не знал материал, я бы ничего не понял.

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

Это два моих скромных совета

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

Упоминаешь «атрибут», а что это такое? Потом напишешь «кортеж» и догадывайтесь сами, что это?

Иллюстрация к комментарию

> Реляционная база данных — это тело

Што? Какой-то непонятный изъёб, дабы придать тексту флёр академичности. Проще будь, ТС, тут тебе не хабр с яйцеголовыми. И да, хватит уже путать понятия данных и информации. Хранилища информации называются базами знаний. А БД в самом своём названии содержит подсказку.

А нахуй звезду собирать? Это в ассоциативных системах, в обычных РБД то зачем?

И ANSI синтаксис таки все поддерживают, нюансы определенных систем можно уже на ходу узнать. Реальная разница начинается в расширениях типа PL или Transact

Отвратительно. Тут же дети, прошу не вываливать вот это вот тут.

это общеобзорная статья на то, что такое SQL. Примеры обязательно будут, если нужно продолжение)

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

А за это определение — расстрелять нахуй. Без права переписки.

Не нужно. В инете этого полно.

Зачем это здесь? есть профильные сайты на которых можно нормально и грамотно учиться.

Почему каждый кто найдёт информацию в интернете начинает воображать себя невьебенным учителем?

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

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

Хороший материал могут написать не все. Для этого много чего нужно знать и уметь применять. А у тебя получилось как у Малышевой — «просто» о сложном. Только она в телек пошла, а ты на пикабу. Не нужно упрощать, информация должна быть полной и точной.

Вся информация в строке привязана к какому-то одному атрибуту — он и будет называться Первичным Ключом. Он — основа вашей системы записи в файл; и когда вы хотите найти определенную строку в таблице, вы ссылаетесь к этому первичному ключу.

Кроме того, первичные ключи гарантируют, что ваши данные имеют определенную целостность.

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

Ты б ещё сопромат сюда притащил!

Когда для тебя SQL это не просто буквы

Когда для тебя SQL это не просто буквы

О печальной защите информации в 2017 году

В данном посте я хочу поговорить не про гигантов типа Google, Яндекс или ВК, а про обычные компании с которыми мы работаем или которые не так известны.

Несмотря на кучу законов типа ФЗ-152 уровень защищенности персональных (и не только) данных к сожалению переживает по моим наблюдениям не лучшие свои времена.

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

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

Вооружившись VirtualBox с установленным внутри WireShark и другими средствами мониторинга начал следить за программой, исследовал формочки приложения. В WireShark промелькнул HTTP-запрос, отправляющий сообщение на сервер. Так же обнаружил и HTTP-запрос, получающий сообщения с сервера. Немного поразбежавшись, обнаруживаем, что никакой авторизации на стороне сервера нет. Получаем сразу 2 уязвимости. Мы можем читать сообщения любого пользователя, включая, что пишут админу, а так же от имени пользователя отправлять сообщения другому пользователю.

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

Попалась на глаза мне контекстная реклама одной фирмы, которая говорила, что есть филиалы во многих городах РФ. Что-то тогда меня заинтересовало и я открыл их сайт.

Там открыл форму обратной связи.

С удивлением замечаю попадаю на сайт без домена, а только IP-адрес сервера.

Стало любопытно, а что работает на этой машинке? Проверяю порт FTP и… захожу под гостем. Куча всяких файлов, рабочая WEB-папка со страницами сайта. Есть немножко бэкапов. С виду сервер использовался как или помойка или как тестовый сервер.

Открываем файл конфигурации из Web-папки … Видим логин и пароль от FTP-другого сервера.

Проверяем… И попадаем уже во второй сервер…

Там тоже поднят WEB-сервер и вообще файлов намного больше… на 200 гигабайт с лишним. В основном это конечно бэкапы баз, но и очень много рабочих и свежих документов.

Внутри конфига WEB-сервера уже засвечивается и SQL-сервер с логином и паролем, который крутится на этом сервере. И да. На него тоже можно попасть.

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

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

В голове вместе с алгоритмом парсера и количество срок кода росла также лень всё это делать. Тогда я решил проверить теорию с предыдущим сервером. И.. Вы не поверите! Ситуация практически повторилась! Мы опять попали на FTP сервер, но на этот раз там лежал файл VPNRouter_64.vmdk. Виртуальная машинка.

Немного колдуем над файлом и получаем доступ к разделу виртуального диска внутри машинки.

Самое интересное, это папка OpenVPN с настроенной конфигурацией и сертификатами.

Копируем на свой комп, подключаемся, и… Бинго! Мы внутри защищенной сети.

Смотрим какой нам присвоил сервер виртуальный IP.

Открываем терминал, запускаем nmap сканируем всю подсеть на 80,21,1433 порты.

Есть несколько компьютеров с такими открытыми портами!

И опять нас радостно встречает FTP без пароля на одном из серверов!

А дальше классика. Открываем Web.config, получаем строку подключения к серверу и с помощью dBeaver мы получаем доступ к базе данных внутри сети. Что еще интереснее, данная комбинация подошла и на другие SQL-сервера внутри этой сети. Один пароль на все сервера (всего их было 3-5 серверов, уже не помню). И это довольно крупная бюджетная организация для нашего региона!

Опять же возможность положить сайты, совершить утечку персональных данных (я там себя нашёл), исказить/удалить.

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

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

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

В таком режиме мы уже работаем давно, но программист написавший программу уже уволился, а неудобства с программой проявляются все сильнее и мысли написать свою программу типа плагина или хотя бы нужные скрипты. И тогда я решил провести один эксперимент, а именно попробовать подключиться не через их прогу, а через редактор БД. Выдергиваю, по какому адресу их программа стучится, вбиваю в редактор БД, и… сервер нас впустил! Ему хватило подключения по VPN и доверительное соединение! Мы опять получаем доступ к серверу ко всем базам, которые там находятся со всеми вытекающими, куда по идее мы не должны были попасть.

Похожая ситуация и в самой корпоративной сети, опять же в этом году.

Дали программу, файл реестра, внутри которого… Логин sa, пароль 111111As…. Доступ из внешки… Ну хоть не на стандартном порту. А на нем так же крутиться персональная информация! Любой админ из корпоративной сети сути может увидеть инфу другого филиала через SQL-редактор, к которой он не должен иметь доступа, а так же изменить/удалить всю БД! А то что изначально дали доступ без защищенного канала еще хуже! Благо щас перевели программу на Vipnet, но пару месяцев назад доступ по внешнему IP еще был, может и до сих пор есть.

Недавно проводил исследование одного Android-приложения (мой предыдущий пост), там такая же плачевная ситуация. Любой школьник может получить доступ к информации без авторизации, слить бюджет на СМС, зафлудить СМС чей нибудь телефон, исказить рейтинг, слить базу данных. Так же существует возможность получить права баристы простым брутом пароля!

Это всё печально дамы и господа. Давайте, мы будем относиться к защите наших серверов/ПК/телефонов более серьезно. Для проникновения внутрь не понадобились никакие эксплоиты, хакерские навыки. Только штатные программы и любознательность.

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

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

Многие этим профессионально занимаются, пишут ботов которые ползают по интернету, пробивают стандартные порты, брутят по словарю, ломают роутеры, IP-камеры, увеличивая армию ботов. С такими ботами встречался и я, точнее мой Firewall и было занятно наблюдать как пытались подобрать пароль от моей базы по примерно по 5-10 запросов в секунду.

Так же попадались боты которые пытались ломануть мой FTP и VNC сервер из разных стран.

Обнаружив эти попытки в логах, я убрал компы за NAT и с тех пор я держу все порты закрытыми, оставив только порт для VPN-соединения, а при, необходимости временно доступа другим людям, открываю временно их на нестандартных портах. Для постоянно доступа использую OpenVPN и генерирую сертификаты на каждое устройство.

Итак. Для минимальной безопасности:

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

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

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

4. Если возможно, старайтесь в Андроид-приложениях шифровать все HTTP-запросы. Например http://127.0.0.1/web?query=vcXGregfds4r5f3r456sdr32vdf-6t и ответ получать примерно такой же. Через снифер уже не будет видна какая-либо зависимость от запросов и большинство любителей это уже может остановить. В идеале еще прикрутить защищенное соединение, но многих останавливает, что SSL-сертификаты платные. Можно еще использовать сокеты.

5. Не оставляйте в приложениях права админа, например в веб-приложениях, десктопных. Старайтесь давать минимальные права приложениям. Фукнции авторизации желательно вешать на сервер, а дальше посылать только ID-сессии, а не UserID. При обмене данными всегда проверять авторизована ли машина или нет. Особенно это касается Web- и Android-приложении.

6. Периодически проверяйте логи приложений, а так же лог фаервола.

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

8. Ну про своевременную установку патчей и обновлений, я думаю не стоит объяснять.

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

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

https://pikabu.ru/story/sql_dlya_chaynikovrelyatsionnyie_bd_tipyi_dannyikh_7575706

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Related Posts