[Local Link Removed for Guests] писал(а): [Local Link Removed for Guests]29 июл 2023, 21:13
[Local Link Removed for Guests] писал(а): [Local Link Removed for Guests]29 июл 2023, 19:07
среднестатистический опер Василий
Мне кажется не совсем удачный пример. В стране десятки тысяч наверное таких Василиев и проще запилить им морду под конкретную задачу руками нескольких программистов. Опять же в идеале опера (гибддшники, приставы, нотариусы и прочие) должны получать АКТУАЛЬНУЮ информацию в режиме реалтайм от нужных им структур. Например посредством API. Базы должны вестись соответствующими ведомствами. Андрюха, у нас труп! Возможно, криминал! Дуй на "горбушку" за диском с базами. По мне подход устарел. При этом у меня самого скажем так есть софт который вполне легально (ну ок, с программной рекапчей) запрашивает инфу у госструктур и эта инфа сразу оседает у меня в базе.
И да, к своему стыду возможно я несколько тупее Василия. Я уже лет 10 периодически кручу Кронос, после 10 летнего опыта мускуля (ну это же круче чем компьютер в школе?) и так и не могу его нормально понять и освоить. Я не спорю что он имеет место быть, особенно после баз 2000х годов где чуть ли не у каждой была своя оболочка, но толком понять Кронос не могу. Хотел бы еще техническое сравнение одинаковых баз в Мускуле и Кроносе по размеру и скорости работы. Мускуль базу я могу правильную сделать, но вот в Кроносе возможно из-за незнания буду необъективен.
Вот о чем и разговор
Если ты и такие специалисты будете вести датацентр, к которому подключат оперов Василиев, а самим операм дадут ссылку на
пробигугл.рф - это будет правильно и круто. И думаю, что когда-то именно к такому всё и придёт. Тот же Кронос постепенно в эту сторону рулит, но со свойственными ему усложнениями. Ну не могут наши производители сделать сразу как надо.
Не защищаю Кронос и согласен с твоей оценкой, он чрезмерно усложнен. Но заставить среднестатистических оперов поднимать у себя в отделе сервер SQL, писать под него морду или делать запросы вручную и с помощью ТерминаторGPT, а перед этим ещё форматировать файлы с базами данных под всю эту конструкцию - это не проще чем работать с Кроносом.
Опера Василии конечно со временем приноровятся, но им будет немного некогда выполнять другую свою работу, опера станут не операми, а администраторами
Ты посмотри на базы, которые я выкладываю, там всё в одном файле, у которого один заголовок. Я ещё правда трачу время на приведение строк в один вид, чтобы местные пользователи могли без особых проблем запихнуть это всё в Кронос, хотя для меня и моих поисковых систем это не критично, как там уехали поля, где сначала идёт телефон, а потом ФИО и прочее.
В случае с SQL и базами под Кронос нужен строжайший порядок, а это большие затраты времени, машинных мощностей, это некоторые знания в обработке файлов, для этого нужны свои специалисты, и если они есть - всё круто, а вот в противном случае опять же рулит нереляционная СУБД.
Вопросы актуализации и контроля тоже решаются.
И ещё момент с SQL.
Вот ты приводишь в соседней теме пример с таблицей пользователей вконтакте, у тебя для примера три файла.
Файл 1 {ФИО и ВК ИД}:
Ашот Базокрадов|vkid12345678
Файл 2 {Телефон и ВК ИД}:
79991231231212|vkid12345678
Файл 3 {Дата рождения и ВК ИД}:
31.02.1900|vkid12345678
Вот эти три файлика SQL сервер читает и объединяет строки на основе ВК ИД, и всё удобно и понятно.
А теперь представь, что база на 700 МИЛЛИОНОВ строк
Получается три файла, в каждом из которых повторяется ВК ИД.
Получается что вместо одного раза vkid12345678 пишется ТРИ раза.
В масштабах 700 миллионов записей это сколько лишних гигабайт получится?
А если таких баз тысячи?
Тут нужно как-то хитрее подходить к вопросу, как-то правильнее организовывать хранение.
Нереляционка позволяет заархивировать текстовый файлик, у которого лишь одна строчка в шапке ТЕЛЕФОН|ФИО|ПОЧТА|АДРЕС
Потом создаётся индекс, который весит примерно на 30 процентов больше, чем файл с оригинальной таблицей {вместо гигабайта база будет весить 1.3 гигабайта}, и всё на этом, потом СУБД работает с этим индексом, причём работает быстро.
А вот в чём настоящая проблема - у нынешних нереляционных СУБД нет возможности редактирования файлов, как это можно сделать с SQL или Кроносом, но никто не мешает открыть его в текстовом редакторе и там сделать всё, что нужно.
И снова подмечу. Вот у тебя папка с текстовыми документами, в которой свободно изложены резюме и просто текст, в массиве текста есть ФИО, есть телефоны, есть электронные адреса. Каким образом это можно быстро превратить в базу данных?
Кронос и SQL потребуют найти нужные фрагменты и превратить это в таблицу, в то время как нереляционная СУБД просто просканирует эту папку с документами, а потом позволит сразу искать во всём массиве данные о телефонах, электронной почте и ФИО.
Да, весить этот индекс будет много, там будет много мусора, но в некоторых случаях это может в прямом смысле спасти жизнь.
Опять же не критикую SQL, наоборот, поддерживаю и такое развитие тоже, это интересно и это один из вариантов будущего, в особенности для государственных ведомств, но хочу чтобы сразу людям было понятно, что это путь не для всех.
