Итак, название немного кликбейтное. Но выслушай меня, я мог бы кое-что здесь… может быть…
В течение последнего года или около того меня беспокоило то, как мы просматриваем наши данные. В течение многих лет у нас был стандартный ERD, используемый большинством баз данных SQL, а совсем недавно у нас появилось дерево NoSQL JSON. Я уверен, что есть и другие, но нет ничего лучше или логичнее.
Там должен быть лучший способ.
Я еще не знаю, что это за путь. Я жду своего Дока Брауна, ударился головой о прилавок, видение момента конденсатора потока, где я чудесным образом вижу мысленным взором решения моей проблемы. Тогда я потрачу все свое семейное состояние, чтобы построить его.
Пытаться объяснить это все равно, что думать о своем сне: чем больше вы пытаетесь сосредоточиться на нем, тем больше он ускользает. Имеет ли это смысл?
Почему это проблема?
Честно говоря, это не проблема. Но то, что это не проблема, не означает, что нет лучшего решения.
Что я думаю, что это МОЖЕТ быть
Итак, опять же, никаких подсказок, так что здесь просто плевать, но думаю, что ответ может заключаться в трехмерных базах данных. Я понятия не имею, что это вообще значит.
Проблема с NoSQL заключается в том, что ваши данные могут стать очень кластеризованными и сложными для запросов, потому что вы используете денормализованные данные. Но если вы попытаетесь нормализовать свой NoSQL, ваши запросы окажутся в затруднении. Это также хорошо масштабируется с большим, постоянно обновляемым приложением. В то время как традиционные базы данных SQL, по мере их роста, вы получаете так много справочных таблиц, что ваши запросы содержат 32 соединения. Оба варианта имеют одинаковые списки противников противодействия (возможно, на другой день).
Тем не менее, на деревья данных NoSQL приятно смотреть, посмотрите Firebase, и использование данных может быть еще проще, по крайней мере, из коробки. В то время как SQL обладает преимуществами мощности запросов и нормализации, чтение диаграмм ERD отстойно, особенно в больших приложениях.
Счастливая среда
Возможно, идея трехмерных баз данных могла бы это исправить. Модели данных с вложенными отношениями родитель-потомок располагаются поверх основных таблиц поиска, или вместо строк данных в ваших таблицах его стеки данных с вашими моделями данных создают структуру. Возможно, лучше было бы использовать термин Гибрид SQL — NoSQL, что-то среднее между двумя концепциями.
Я не знаю. Это всего лишь некоторые идеи и бессвязная болтовня скучающего разработчика за работой, который не хочет начинать какие-либо новые задачи, потому что сейчас 4:15, а я пропустил обед, и я ухожу в 4:30, а мой Adderall сходит на нет. хочу играть в покемонов.
Серьезно, дайте мне знать, что вы думаете об этом.
