Не только. Я бэк интегрировал с Epic Online Services. Они требуют чтобы работа с апи была в единственном потоке. Плюс обёртка над их коллбеками для async/await. Пришлось писать свой SynchronizationContext (реализация sc для одного потока из vs не подошла)
Написать аналог Asteroids. Логика независима от представления. Время неограничено. Ок, потратил часов 10.
Ответ: примененные вами подходы не работают в случае большого количества объектов и большого разнообразия логики. И вообще присмотритесь к ecs. Приходите через пол года.
Чего!? Строить ecs для приложения где по ТЗ и не предполагается не то что тысяч, даже сотен объектов? И как я должен был понять что им надо расширяемое приложение? Есть четкое ТЗ, с четкими требованиями. Оно готово.
Полки в шкафу можно превратить в хаос, который будет явно неупорядоченным. В базу можно тоже напихунькать всякого разного не туда, и тоже получится хаос.
Я и не говорил, что нельзя. Но полки дают возможность структурировать данные. В отличии от их отсутствия.
Но ведь «БД, используящая файлы» ≠ «просто любые файлы».
Вы же опять себе же и противоречите. Нет особых файлов в которых находятся БД. Давайте посмотрим определение БД: «Хранилище структурированных данных». Всё. Тут нет ни слова о виде хранилища. Память, файлы, магнитная лента… перфокарты… Так что да, любой файл содержащий структурированные данные — БД. В том числе и «простые текстовые файлики».
А у новичка это утверждение все эти вопросы не вызовет, а для понимания вполне понятно.
Как написано, так и запомнит. Значит в будущем у новичка будут проблемы когда возникнут вопросы, или он столкнется с другой реализацией.
Есть, для связи таблиц
Это не объяснение. Что за связи? Зачем? Что будет, когда новичку дадут отлично функционирующую реляционную БД без единого foreign key? Почему вы думаете что на собеседовании не спросят что такое связи, зачем они нужны, и можно ли без них обойтись?
А начинающая статья никогда не сделает человека специалистом.
Никогда. Зато всегда может помешать в адекватном восприятии дальнейшей информации.
Что я могу сказать. Прочитав статью, я лишь подтвердил что в ближайшее время кризис на рынке it специалистов, в ближайшее время, не решится.
Это не материал для обучения специалистов, это материал для их убийства.
При таком подходе к предоставлению информации может и даст человеку набор тезисов, но действительного понимания не дает абсолютно. Хотя автор утверждает что статья направлена на
общее понимание «а что это вообще такое»
У автора также проблемы с пониманием СУБД — БД. Из-за чего по тексту так-же возникают фундаментальные ошибки.
=====
База данных — это место для хранения данных.
Неверно. База данных — это место для хранения структурированных данных.
Если говорить аналогиями, то мешок — это не БД, а шкаф с полками — вполне себе. Только лишь потому что в шкафу с полками, можно структурировать содержимое.
Отсутствие одного слова сразу ломает все понимание сущности БД, что не дает на его основе делать правильные самостоятельные выводы.
Используется в клиент-серверной архитектуре
Клиент-серверная архитектура при использовании БД — это лишь частный случай. Это утверждение сразу зарезает понимание того что БД можно использовать и в других случаях. Например: [ Клиент ] => [ СУБД ] => [ БД ]
[ Клиент [ СУБД ] ] => [ БД ]
и чем она лучше хранения информации в простых текстовых файликах
Из этого утверждения можно сделать неверный вывод, что текстовые файлики не могут выступать в роли БД.
Автор этим утверждением противоречит сама себе, как собственному определению БД, так и дальнейшим утверждением что существуют БД, использующие текстовые файлы.
Мы еще до содержания не дошли, а у читателя уже фундаментальные ошибки в понимании что такое БД и как оно используется.
Если приложение небольшое, отдельная база не нужна. Но потом это становится удобнее и выгоднее с точки зрения памяти.
Утверждение порождающее больше вопросов чем ответов. Если приложение небольшое — это значит что БД ей совсем не нужна? Или нужна в составе самого приложения? Но ведь БД, по предыдущим определениям, не может быть кроме как за бэкендом. Что такое отдельная БД? Насколько небольшим должно быть приложение? Размер приложения — это размер билда или объем хранимых данных?
Автор только что привязала наличие БД и его местоположение к размеру приложения. Что фундаментально неверно. Большинство приложений имеет БД в том или ином виде. Объем хранимых данных на одного пользователя в большинстве случаев не превышает объем памяти устройства на котором находится приложение. Внешнее БД используется в основном для агрегации, централизованного доступа к данным, их синхронизации и обработке.
Тоже самое и в приложениях. Если приложение маленькое, то все данные можно хранить в памяти. Но учтите, что это память на вашем компьютере, вашем телефоне. И чем больше данных туда пихать, тем медленнее будет работать программа.
Место в памяти ограничено. Поэтому когда данных много, их нужно куда-то сложить. Можно писать в файлики, а можно сохранять информацию в базу данных (сокращенно БД). Выбор за вами. А точнее, за вашим разработчиком.
Эти абзацы следуют из предыдущих и только усугубляют проблему. Ведь БД тоже занимает место. Конечно автор этими словами хочет обосновать свою позицию в использовании БД как внешний сервис в клиент-серверной архитектуре. Но это никак не связано с пониманием того для чего вообще БД используется.
Да примерно как excel-табличка
Очень притянуто за уши и только как частный случай.
Это называется реляционная база данных — набор таблиц, хранящихся в одном пространстве.
Автор дальше пытается уничтожить вообще любое понимание что такое БД. С этим определением реляционными можно назвать и документные БД. Автор абсолютно не понимает что значит реляционные, хотя дальше использует его понятия.
Хранение данных в виде табличек — это не единственно возможный вариант. Вот вам для примера запись из таблицы в системе Users. Там используется MongoDB база данных, она не реляционная. Поэтому вместо таблички «словно в excel» каждая запись хранится в виде объекта
Пляска на гробу. Автор тут утверждает что MongoDB — не реляционная БД потому что она хранит объекты виде объектов, а не таблиц.
Таблица — представление данных. Данные из Mongo можно также представить в виде таблицы. Как и данные из MySql представить в виде объектов.
А еще есть файловые базы — когда у вас вся информация хранится в файликах. Да-да, простых текстовых файликах!
Тут у читателя происходит когнитивный диссонанс.
моя задача — объяснить «что это вообще такое» для ребят, которые базу в глаза не видели.
На данный момент у ребят уже сложились понимание, которое никак не связано с реальностью. Если вообще сложилось.
Дальше автор приводит некоторые примеры для работы с SQL. В принципе норм.
Но тут на сцену влетает foreign key!
Во первых: начинающему эта информация будет несколько сложноватой. особенно с абсолютным непониманием что такое реляционная БД.
Во вторых: foreign key по дальнейшим примерам создается, но не используется. Объяснения зачем он нужен нет.
Индексы. По тексту получается, что они сортируют данные в таблице. Часто встречал такое представление у «специалистов». Видимо тоже учились по таким материалам.
Преимущества базы данных
Каких и в сравнении с какими?
Почему используют базу, а не сохраняют данные в файликах?
БД тоже находятся в файликах
Может автор имела ввиду СУБД?
Базы поддерживают требования ACID (по крайней мере транзакционные БД)
Т.е все таки показываются преимущества именно транзакционных СУБД?
Это единый синтаксис SQL, который используется повсеместно
Еще и реляционных
Так может вывести в заголовок «Преимущества транзакционных SQL СУБД»?
Потому что эти пункты никак не относятся к преимуществам использования самих БД
=====
Автор совсем не разбирается в вопросе который она подняла. А конкретно: что такое БД. Не говоря уж о том что такое СУБД. Для чего они нужны и как их используют.
Видимо для ее квалификации на той должности на которой она находится большего и не надо.
Но чтобы не стать очередным некомпетентным «специалистом», которыми весь IT рынок завален, такие статьи обходить стороной.
=====
Какие выводы я сделал. Пока существуют такие материалы, стоимость меня как специалиста будет только расти.
Не только. Я бэк интегрировал с Epic Online Services. Они требуют чтобы работа с апи была в единственном потоке. Плюс обёртка над их коллбеками для async/await. Пришлось писать свой SynchronizationContext (реализация sc для одного потока из vs не подошла)
Ох. Я похожим образом тестовое в Кефир проходил.
Написать аналог Asteroids. Логика независима от представления. Время неограничено. Ок, потратил часов 10.
Ответ: примененные вами подходы не работают в случае большого количества объектов и большого разнообразия логики. И вообще присмотритесь к ecs. Приходите через пол года.
Чего!? Строить ecs для приложения где по ТЗ и не предполагается не то что тысяч, даже сотен объектов? И как я должен был понять что им надо расширяемое приложение? Есть четкое ТЗ, с четкими требованиями. Оно готово.
Я и не говорил, что нельзя. Но полки дают возможность структурировать данные. В отличии от их отсутствия.
Вы же опять себе же и противоречите. Нет особых файлов в которых находятся БД. Давайте посмотрим определение БД: «Хранилище структурированных данных». Всё. Тут нет ни слова о виде хранилища. Память, файлы, магнитная лента… перфокарты… Так что да, любой файл содержащий структурированные данные — БД. В том числе и «простые текстовые файлики».
Как написано, так и запомнит. Значит в будущем у новичка будут проблемы когда возникнут вопросы, или он столкнется с другой реализацией.
Это не объяснение. Что за связи? Зачем? Что будет, когда новичку дадут отлично функционирующую реляционную БД без единого foreign key? Почему вы думаете что на собеседовании не спросят что такое связи, зачем они нужны, и можно ли без них обойтись?
Никогда. Зато всегда может помешать в адекватном восприятии дальнейшей информации.
Это не материал для обучения специалистов, это материал для их убийства.
При таком подходе к предоставлению информации может и даст человеку набор тезисов, но действительного понимания не дает абсолютно. Хотя автор утверждает что статья направлена на
У автора также проблемы с пониманием СУБД — БД. Из-за чего по тексту так-же возникают фундаментальные ошибки.
=====
Неверно. База данных — это место для хранения структурированных данных.
Если говорить аналогиями, то мешок — это не БД, а шкаф с полками — вполне себе. Только лишь потому что в шкафу с полками, можно структурировать содержимое.
Отсутствие одного слова сразу ломает все понимание сущности БД, что не дает на его основе делать правильные самостоятельные выводы.
Клиент-серверная архитектура при использовании БД — это лишь частный случай. Это утверждение сразу зарезает понимание того что БД можно использовать и в других случаях. Например:
[ Клиент ] => [ СУБД ] => [ БД ]
[ Клиент [ СУБД ] ] => [ БД ]
Из этого утверждения можно сделать неверный вывод, что текстовые файлики не могут выступать в роли БД.
Автор этим утверждением противоречит сама себе, как собственному определению БД, так и дальнейшим утверждением что существуют БД, использующие текстовые файлы.
Мы еще до содержания не дошли, а у читателя уже фундаментальные ошибки в понимании что такое БД и как оно используется.
Утверждение порождающее больше вопросов чем ответов. Если приложение небольшое — это значит что БД ей совсем не нужна? Или нужна в составе самого приложения? Но ведь БД, по предыдущим определениям, не может быть кроме как за бэкендом. Что такое отдельная БД? Насколько небольшим должно быть приложение? Размер приложения — это размер билда или объем хранимых данных?
Автор только что привязала наличие БД и его местоположение к размеру приложения. Что фундаментально неверно. Большинство приложений имеет БД в том или ином виде. Объем хранимых данных на одного пользователя в большинстве случаев не превышает объем памяти устройства на котором находится приложение. Внешнее БД используется в основном для агрегации, централизованного доступа к данным, их синхронизации и обработке.
Эти абзацы следуют из предыдущих и только усугубляют проблему. Ведь БД тоже занимает место. Конечно автор этими словами хочет обосновать свою позицию в использовании БД как внешний сервис в клиент-серверной архитектуре. Но это никак не связано с пониманием того для чего вообще БД используется.
Очень притянуто за уши и только как частный случай.
Автор дальше пытается уничтожить вообще любое понимание что такое БД. С этим определением реляционными можно назвать и документные БД. Автор абсолютно не понимает что значит реляционные, хотя дальше использует его понятия.
Пляска на гробу. Автор тут утверждает что MongoDB — не реляционная БД потому что она хранит объекты виде объектов, а не таблиц.
Таблица — представление данных. Данные из Mongo можно также представить в виде таблицы. Как и данные из MySql представить в виде объектов.
Тут у читателя происходит когнитивный диссонанс.
На данный момент у ребят уже сложились понимание, которое никак не связано с реальностью. Если вообще сложилось.
Дальше автор приводит некоторые примеры для работы с SQL. В принципе норм.
Но тут на сцену влетает foreign key!
Во первых: начинающему эта информация будет несколько сложноватой. особенно с абсолютным непониманием что такое реляционная БД.
Во вторых: foreign key по дальнейшим примерам создается, но не используется. Объяснения зачем он нужен нет.
Индексы. По тексту получается, что они сортируют данные в таблице. Часто встречал такое представление у «специалистов». Видимо тоже учились по таким материалам.
Каких и в сравнении с какими?
БД тоже находятся в файликах
Может автор имела ввиду СУБД?
Т.е все таки показываются преимущества именно транзакционных СУБД?
Еще и реляционных
Так может вывести в заголовок «Преимущества транзакционных SQL СУБД»?
Потому что эти пункты никак не относятся к преимуществам использования самих БД
=====
Автор совсем не разбирается в вопросе который она подняла. А конкретно: что такое БД. Не говоря уж о том что такое СУБД. Для чего они нужны и как их используют.
Видимо для ее квалификации на той должности на которой она находится большего и не надо.
Но чтобы не стать очередным некомпетентным «специалистом», которыми весь IT рынок завален, такие статьи обходить стороной.
=====
Какие выводы я сделал. Пока существуют такие материалы, стоимость меня как специалиста будет только расти.