>Зачем это всё и почему оно такое переусложенное?
Для удобства
> Почему нельзя просто вбить все данные в таблицу?
База данных состоит из таблиц, если че
>Акцесс
>Базы данных
Проиграл
вбей в таблицу эксель 50млн записей, потом попробуй найти что-нибудь, отредактировать, сохранить, расскажешь потом понравилось ли
Например, у тебя есть таблица врача Пупкина, у него есть много пациентов.
Ты выстраиваешь между ними реляцию One(врач)-to-Many(много пациентов)
Таким образом, ты можешь легко получать в таблице врача всех пациентов, которые у него есть или у пациента смотреть, кто его врач.
но ща меня говном закидают, я всего лишь начинающий бэкэндер
Разве что за «реляцию» говна въеби, а так в целом всё верно. Связь говори, ты ж русский человек
Вот этот >>257545353 всё рассказал по сути.
>Логичным решением будет использовать Эксель, который как раз и предназначен для работы с таблицами.
Эксель не подойдет, если
1. Монго данных.
2. Ты пишешь приложение, которое обменивается данными с табличкой.
3. Много пользователей данных одновременно.
4. Требуется быстрый поиск по запросу.
Связь бывает только половая между мной и твоей мамашей, а в контексте рбд есть только релейшны.
>Зачем это всё и почему оно такое переусложенное? Почему нельзя просто вбить все данные в таблицу?
Если для тебя "данные" ограничиваются лишь одной таблицей - тогда пользуйся экселем на здоровье, и во всякие акцессы не лезь. Тебе в треде уже всё рассказали.
>>257545245
ну, для ОПа "база данных" - это пара табличек, в которых он ведет учёт своих домашних доходов-расходов. Чего ты докопался то?
На одной работе вся информация была в экселевских таблицах, а там несколько миллионов записей, и этими файлами пользовались многие одновременно (из-за чего была проблема, когда нельзя было ничего в таблицу сохранить, потому что какой-нибудь червь-пидор забыл файл закрыть).
ОП не слушай псевдоайтишников, которые кукраекают тут ОП ТУПОЙ ЗУМЕР, ДУМОЕТ ЧТО БАЗЫ ДАННЫХ ЭТО ИКСЕЛЬ, КАКОЙ ЖЕ ПОРИДЖ ТУПОЙ, РЯЯЯЯ
Вся хуйня из других программ выгружается на изи в формат xslx, в экселе помимо стандартных набор есть и макросы и команды.
Чтоб не парсить 10ТБ сырых данных, когда нужно достать один int.
P A X A
Быстрее нежели открыть 10тб файл в экселе
>SQL таблицы
лол! шта?
очепятка
SQL бд*
так ты же сам сейчас и дал пример базы данных, которую нельзя хранить в экселе потому что:
1. Проблема с доступами. В реляционных БД это решается уровнями изолированности транзакций. Любая операция на изменение, добавление или удаление данных осуществляется через транзакции, а не через "в данный момент вы не можете вносить изменения, потому что документ в данный момент редактируется пользователем червь-пидор "
2. Быстродействие. Выше тебе дали пример БД, которая состоит из 50 миллионов строк. Действительно, попробуй ка по взаимодействовать с такой таблицей. Хотя бы на уровне элементарной выборки данных. В экселе у тебя эта операция может занять несколько минут. Тут, в реляционной бд в игру вступают так называемые кластерные и некластерные индексы. Как думаешь, эксель дружит с ними?
3. Целостность данных. Допустим, у тебя есть две таблицы. Таблица с людьми и таблица с их адресами, где они живут. То есть, город, улица, дом, квартира. Каждая строчка с адресами может ссылаться на конкретного человека в таблице людей. Скажи, имеем ли мы право удалить строчку из таблицы с людьми, если на эту строчку ссылается строчка из таблицы с адресами(а то и не одна) ? Как минимум, при попытке удалить человека, система должна запрашивать у пользователя - "а что мы будем делать со строками с его адресом, где он живёт? Эти строчки тоже удалить?". Это я привёл тебе простейший пример.
4. Безопасность данных. Скажи, твой эксель, может без помощи Windows, сам каждые пол часа делать бэкап всех таблиц? Причём делать это так, чтобы не нарушать работу пользователей, которые в данный момент работают с ней? А база данных может.
И это лишь самые элементарные и общие примеры. Если еще что-то вспомню - допишу.
Он имел ввиду, что SQL - это язык, что подразумевается последней буквой, который работает с данными, а то что ты рассказал - это концепция реляционных баз данных. Т.е. корректнее не использовать слово SQL потому что оно не относится к самой идее использования таблиц
>SQL бд*
и такого тоже нет
А как эти ваши БД в плане секса с питоном?
Postgres и mongo.
Остальное для вкатунства нахуй не надо, при необходимости обучат уже на рабочем месте.
ебать ты душнила
Эксель работает только с данными в первой форме по типу
Донос в РКН
Анон1 Тред1
Анон1 Тред2
Анон1 Тред3
Анон2 Тред1
Во многих случаях - это норм, но в примере такое хранение избыточно поскольку строки дублируют инфу и можно просто завести таблицу с анонами и тредами и установить связь между записями в таблице, что будет занимать меньше места и искать треды, в которых сидел анон можно будет быстрее
Между прочим, очень зря.
все ровно, анончик
ты просто не рассказывай то, что тебе не понятно, а то хуиту полную несешь
Чел 1
1) весёлый
2) безответвенный
3) работает в залупа нейм
4) знаком с челом 3
Чел 2
1) знаком с челом 3
2) враг
Чел 3
1) знаком с челом 1
2) знаком с челом 2
3) алкаш
Что бы можно было удобно искать/фильтровать людей по характеристике, что бы можно было посмотрет,ь какие чехлы с кем пересекаются.
Никто тебе не мешает создать реактивную связь через ВПР.
Электронные таблицы больше для ручной работы и в более свободной форме. Таблицы в базе данных сильнее ограничены. В одном столбце может быть только один тип данных.
Пока данных не очень много и в экселе норм, но когда размер становится слишком большим эксель, из-за того, что обновляет форматирование и вычисления в ячейках в реальном времени, начинает тормозить или может быть, что данные в него не лезут, так как там ограничение 65к на 65к ячеек.
А из базы делают выборки данных, поэтому эй не надо что-то там постоянно перерисовывать на экране и производительность от этого сильно возрастает. К тому же с базами может работать не один пользователь. Короче вроде в основе и там и там таблицы, нл с разными возможностями и ограничениями и для несколько разных задач.
>там ограничение 65к на 65к ячеек
Nope.
>но когда размер становится слишком большим эксель, из-за того, что обновляет форматирование и вычисления в ячейках в реальном времени
Excel строит зависимости и при изменении какой-либо ячейки обновляет ТОЛЬКО его зависимости and so on.
Нет, не быстрее.
Тебе для построения красно-черного древа из 10 ТБ жсона уйдет уйма времени. За это время ты не одну сотню табличек сможешь распарсить и вынуть нужную тебе строку.
И на SAP
>10 ТБ жсона
Ну если ебанаты все хранят в одном месте, то неудивительно что они должны страдать
Кто дает характеристику? Они сами пишут как вздумается, пишут по форме или ты сам их кодируешь?
>Связь говори, ты ж русский человек
В таком случае, сударь, соизвольте откушать фекалий и вы сами, ибо relation это не link или connection.
А вообще, я, как и анон выше использую терминологию из языка оригинального изобретателя концепции.
Если бы РБД изобрёл мудрый товарищ Си, то я бы, соответственно, называл их каким-нибудь сычуаньскими хранилищами информационных единиц.
Вы можете попробовать изобрести свой подход к управлению данными и назвать его исконно-русским словом, к вашему удовольствию.
Один хрен, когда занимаешься учебными задачами вроде и не понятно, нахрен оно надо. Но в жизни, если использовать инструмент не по назначению, очень легко упереться в ограничения. Как вариант, там, есть csv с данными с 50 счетчиков электроэнергии с интервалом в час за пару лет. Они идут подряд. Допустим, надо их растолкать в таблицу столбцы -счетчики, строки -даты. И уже, эксель, если в него вообще это влезет может часами эти данные переваривать, access лучше но его тоже может клинить из-за накопления промежуточный данных в файле базы, потому, что он не может быть больше то ли одного, то ли двух гб.
Сам
пчел, у тебя какой-то эксель не правильный. Отсортировать несколько десятков строк по наименованию счетчика или даты не требует колоссального количества времени, на это уйдет пара секунд.
>>257549568
>несколько десятков строк
несколько десятков милионнов строк
быстрофикс
А Релятивистская механика тоже должна называться Связная механика? Знаешь знаешь?
Давно известно что анальники не умеют пользоваться экселем, поэтому придумали себе хуйню под названием сукуэль и пишут там что то вроде select govno from mocha и прочую ересь что тетя срака из бухгалтерии сделает в 2 клика
Двачую этого. Мы вот круды реализовали через запрос к серверу, написанном на VBA внутри макросов, которые взаимодействуют с книгой.
>>257550031
Все уже придумано до вас, SQLite так и работает
CREATE TABLE IF NOT EXISTS friends
(
friend_id integer NOT NULL PRIMARY KEY,
first_name character varying(64) NOT NULL,
last_name character varying(64) NOT NULL,
phone_number integer,
home_adress character varying(32),
job_adress character varying(32),
)
Дальше сам давай, я устал
Таблица про скачать/ на этом можно рпасходится
Я не быдло кодер, и в этих ваших программированих ничего не понимаю
бд данных нахуй не нужны, сейчас все в облаках само крутится. Все эти бд - устаревшее говно для пердиксов.
И тут я тебе такой ссу на лицо на пару со своими хранимками на pl/pgsql на 3к+ строк каждая
тимлид двух команд разработчиков БД
Пиздец
А если он безработный?
А если бездомный?
А телефон нахуя интом?
А праймири кей почему интом? Если у тебя несколько серверов с друзьями, то как коллизии разрешать будешь?
Да че там понимать то, даже слабоумный сможет понять
Производительность БД в облаке и их цену видел?
Хранимками на 3к строк ты только себе ссышь. Нахуя так делать?
А что там с производительностью? Амазон на своем AWS живут и не жалуются.
При масштабировании эксель обосрется.
Я же поэтому и не указал NOT NULL в тех строках, где в теории может быть пусто. А чем плох int в этом моменте? Про коллизии я нихуя не знать, поэтому прошу на меня не орать. Мне просто делать нехуй вот чет и написал
Зашитая бизнес-логика сбора разных показателей: либо отчётность, либо выставление счетов клиентам по списку из 80+ услуг, считающихся по разным условиям
И чо, блядь? Я и в экселе могу связи между таблицами в скриптах писать
int в телефоне плох тем, что тебе вряд ли придется делать с ним арифмитические операции, а вот поиск телефона по маске, например, может пригодится. И с интом для этого придется изъебываться.
Использовать инты для id больно потому что сложнее обеспечить уникальность и потому что int внезапно ограничен сверху, гораздо удобней ебануть огромную строку хэш.
Ну то есть вместо поддерживаемого и расширяемого кода у вас лапша на тысячи строк? Хорошо делаете
>поиск телефона по маске
В чем проблема сделать отдельные столбцы под код города, код атс и сам номер телефона? мм? Работать будет даже быстрее.
Так и какой тип данных стоило указать в том моменте, varchar? Курс для начинающих сейчас прохожу и там такие моменты не проговариваются, может подскажешь где про все эти тонкости можно узнать?
Задача разделения телефон на три части настолько не тривиальная, что такие услуги SASS стартапы за деньги предоставляют.
И это все равно не позволит легко искать по маске типа 153. Зачем так ебаться, если можно не ебаться? БД уже давно умеют очень быстро искать по строкам, вряд ли ты что-то выйграешь за счет интов даже на огромных масштабах.
char у тебя фиксированная длинна строки.
Я не знаю где можно такое учить, возможно в каких-нибудь курсах по system desing интервью
У него же даже в новых версиях ограничение в миллион строк. Он больше даже не загрузит.
Не клади число, клади строку.
Кто? Я? Эта хуйня сама создаётся и хуярит инкремент
Гугли диапазон значений для типа своего id
Нет, она в схеме БД указывается. Можно не указывать, тогда не будет.
Монитор купи нормальный. В экселе ограничение масштаба 400%
Зачем масштабировать Эксель? Это же не анус.
Его нет необходимости расширять, это раз. Это все должно собираться внутри одной транзакции, это два, поскольку формируется в рамках одного документа со сквозной нумерацией
О хуях.
О базах данных, очевидно. Это несколько сложнее чем кажется на первый взгляд.
Я вообще ни одного слова не понял. Инты, иды, нуллы, чары - лучше бы реально о хуях говорили. Программисты хуже пидоров, официально.
И что? Просто профессиональный сленг. Когда игрок в ммо начинает затирать другому про дпс, аггро, бл с пулла, ассистим - ты тоже бугуртишь?
Это я понимаю. А программерский не понимаю. Вывод - программисты хуже пидоров, официально. Понапридумывали непонятных терминов, чтобы умнее казаться.
>>257552234
Таблица три года назад создана, но она чистится регулярно, так может всё наебнуться или чо?
Ссышь ты только себе в лицо, хуйлид не могущий в иронию.
Ну а про транзакции в запросах к БД ты не слышал?
Хватит позориться уже
Зачем чистить таблицу вообще? Обычно данные там остаются навсегда
Если достигнете предела (скорее всего 2^32 записей), то запись в таблицу наебнется, если у вас какой-нибудь залупный движок, то может начать переписывать с нуля
Справедливости ради существуют потоковые парсеры и json-итераторы, которые могут достать значение по ключу при этом не выгружая весть файл в память
Поясняю, эксель предназначен в первую лчередь для расчётов, подстановки формул. В ячейках полный рандом, фарш и винегрет, текст, формулы, цифры. Табличка там просто как нечто более удобное для этого. Да, схожесть с БД есть, но эксель не СУБД даже.
Ацесс как раз представляет БД правда так себе бд, да, там тоже есть таблицы. Но в ячейках хранятся данные, их тип определён (числа, текст и т.д.), строятся связи и главная суть всех БД: язык запросов, SQL, язык для извлечения данных из кучи ячеек по заданным параметрам, типа выбрать первые 10 ячеек если их значение больше чем например 3.14.
Но они не могут построить оптимальную структуру для поиска и ищут за O(n)
1) таблица людей
2) справочник видов отношений между людьми
3) таблица отношений между людьми: ид, чел1, чел2, ид отношения
4) справочник характеристик людей: ид, название хар-ки, значение хар-ки (инт, бул, произвольная строка, множество)
5) справочник значений характеристик: ид, ид хар-ки, значение
6) таблица характеристик людей: чел, ид хар-ки, значение
Номера, работу и др. сам раскидывай. Можешь к людям сунуть, можешь отдельными таблицами, мне поебать.
То есть по твоему noSQL БД не СУБД?
Там же тип не определен, ячеек нет, связи не строятся
Не то чтобы сильно удобно, но вполне себе можно.
А еще во всяких бэкенд фремворках для этого есть ORM с драйвером чтобы не надо было ебаться с SQL запросами из питона.
Впрочем есть еще NoSQL DB в которых все немного проще.
Это, конечно, да, но они позволяют хоть как-то работать с такими файлами, и для некоторых задач этого может и хватить.
Проще пока тебе не нужно сделать JOIN
А на хуй они там нужны? Это как промежуточная таблица хранения, из этих данных за день формируется строка в таблицу ответов раз в сутки и больше эта строка и на хуй не нужна
А почему наебнется? В программировании ведь когда доходит до максимума то просто с нуля начинает считать, не?
В твоём JSON нет таких оптимизаций, какие есть в БД. Ты в JSON будешь лопатить весь файл по порядку. А если файл на сотни мегабайт или десятки гигабайт?
Ну если уж хранить как текст, то лучше не json, а csv хотя бы, чтобы не тратить время на поиск парных {}.
NoSQL не для этого. Очевидно же.
Но вот словарики пихать туда самое оно.
Начинает, а на нуле у тебя другие записи. Поэтому нормальная БД тебе просто откажется писать, потому что ноль уже был использован .
Данные обычно не удаляются потому что они есть/пить не просят, если не пригодятся, то хуй с ними, а если понадобятся, то уже не откатишь удаление. Плюс удаление файлов это лишнее место где что-то может пойти не так и похерить нужные данные.
ORM хороши для вещей, которые и так в общем-то тривиальные. А вот сделать что-то сложное, вроде аналитических запросов, с десятком CTEшек при помощи большей части ОРМов просто нельзя, в них не хватает функционала. Да и в ORMах довольно мало контроля над тем, какой именно запрос улетит в базу данных. Частой бывает ситуация, когда ВНЕЗАПНО орм делает 2-3 запроса вместо одного. В общем хуйня для вкатышей-CRUDоделов
Зато у NoSQL шардирование из коробки, иногда лучше изъебаться со структурой, но не ебаться с шардированием
Заебешься транслировать словарные данные в табличные и обратно.
JSON легко входит в NoSQL и данные ищутся эластиком.
Типа автоинкремент? Ну гугли автоинкремент твоей бд, алсо на его тип можно тоже обратить внимание. Ну и загугли переполнение в твоей бд. Ну куда-то в эту сторону. Всё это зависит от реализации твоей бд. Некоторые бд изначально забабаханы так чтобы у тебя скорее места на диске не хватило, чем ты приблизился бы к этой проблеме.
А ты изучи эти темы, будешь потом ньюфагов разводить пограммерскими фингербоксами.
Ну, тут уже зависит от задачи и сколько человекочасов готовы выделить на ее решение. Хочешь поиграть в мамкиного оптимизатора - пишешь свой драйвер или ебешься с кастомными запросами.
Само собой речь не о таблице в 10 строчек, где разницу ты просто не заметишь. Если у тебя десятки и сотни тысяч записей, то начинается совсем другая математика. Какой-нибудь сравнительный запрос с помощью средства базы данных выдаст тебе результат за 5 сек, в то время как поиск по текстовому файлу потребует пару минут.
>Начинает, а на нуле у тебя другие записи.
Я ж говорю, что записи чистятся
Да у Майкрософт же, чо там у них?
А в облаке не БД, ебанько?
Инты это очевидно интенжер, то есть целые числа, типа в столбце должны быть значения одного типа. Остальное хз что несут.
тебе лучше юзать эксель...
когда доживешь хотябы до сводных таблиц и отчетов, тогда сам поймешь