Как прекратить думать “реляционным образом”
вы можете использовать ng-if, потому что он не отображается на html-странице, и вы не видите свой html-тег в inspect ...
<ul ng-repeat="item in items" ng-if="items.length > 0">
<li>{{item}}<li>
</ul>
<div class="alert alert-info">there is no items!</div>
6 ответов
Я думаю, после просмотра нескольких страниц по этой теме, все зависит от типов данных, с которыми вы имеете дело.
РСУБД представляют собой нисходящий подход, где вы, разработчик базы данных, утверждаете структуру всех данных, которые будут существовать в базе данных. Вы определяете, что у человека есть имя, фамилия, отчество и домашний адрес и т. Д. Вы можете обеспечить это с помощью РСУБД. Если у вас нет столбца для HomePlanet Человека, неудачник хочет быть Человеком, у которого HomePlanet отличается от Земли; вам придется добавить столбец позже, иначе данные не могут быть сохранены в СУБД. Большинство программистов в любом случае делают подобные предположения в своих приложениях, так что это не глупая вещь, которую нужно принимать и применять. Определение вещей может быть хорошим. Но если вам в будущем понадобится регистрировать дополнительные атрибуты, вы мне придется добавить их. Модель отношений предполагает, что ваши атрибуты данных не сильно изменятся.
Базы данных «облачного» типа, использующие что-то вроде MapReduce, в вашем случае CouchDB, не делают вышеуказанного предположения, а вместо этого смотрят на данные снизу вверх. Данные вводятся в документы, которые могут иметь любое количество различных атрибутов. Он предполагает, что ваши данные по самому своему определению разнообразны по типам атрибутов, которые они могут иметь. В нем говорится: «Я просто знаю, что у меня есть этот документ в базе данных Person, у которого есть атрибут HomePlanet« Eternium »и имя« Lord Nibbler », но нет LastName». Эта модель подходит для веб-страниц: все веб-страницы представляют собой документ, но фактическое содержимое / теги / ключи документа различаются настолько широко, что вы можете ' Я поместил их в жесткую структуру, которую СУБД проповедует сверху. Вот почему Google думает, что MapReduce модель roxors soxors, потому что набор данных Google настолько разнообразен, что его нужно встроить для двусмысленности с самого начала, а из-за массивных наборов данных можно использовать параллельную обработку (что MapReduce делает тривиальным) . Модель документ-база данных предполагает, что атрибуты ваших данных могут / будут сильно меняться или быть очень разнообразными с «пробелами» и множеством редко заполненных столбцов, которые можно было бы найти, если бы данные хранились в реляционной базе данных. Хотя вы можете использовать СУБД для хранения подобных данных, это очень быстро станет уродливым.
Тогда отвечу на ваш вопрос: вы вообще не можете мыслить «реляционно», глядя на базу данных, которая использует парадигму MapReduce. Потому что это не так на самом деле имеют принудительное отношение. Это концептуальная горбинка, которую вам просто нужно преодолеть.
Хорошая статья, с которой я столкнулся, в которой сравниваются и сравниваются две базы данных довольно хорошо, - это MapReduce: A Major Step Back , в которой утверждается, что парадигма MapReduce базы данных являются технологическим шагом назад и уступают РСУБД. Я не согласен с тезисом автора и утверждаю, что разработчик базы данных просто должен выбрать правильный вариант для своей ситуации.
Все дело в данных. Если у вас есть данные, которые имеют наибольший реляционный смысл, хранилище документов может оказаться бесполезным. Типичная система на основе документов - это поисковый сервер, у вас есть огромный набор данных и вы хотите найти конкретный элемент / документ, документ является статическим или версионным.
В ситуации архивного типа документы могут быть буквально документами, которые не меняются и имеют очень гибкую структуру. Нет смысла хранить их метаданные в реляционных базах данных, поскольку все они очень разные, поэтому очень немногие документы могут использовать эти теги. Системы на основе документов не t хранить нулевые значения.
Нереляционные / документальные данные имеют смысл при денормализации. Это не сильно меняется, или вы не так сильно заботитесь о согласованности.
Если ваш вариант использования хорошо подходит для реляционной модели, то, вероятно, не стоит втискивать его в модель документа.
Вот хорошая статья о нереляционные базы данных .
Другой способ мышления - документ - это строка. Все о документе находится в этой строке и относится к этому документу. Строки легко разделить, поэтому масштабировать проще.
Вот хорошая статья о нереляционных базах данных .
Другой способ мышления - документ - это строка. Все о документе находится в этой строке и относится к этому документу. Строки легко разделить, поэтому масштабировать проще.
Вот хорошая статья о нереляционных базах данных .
Другой способ мышления - документ - это строка. Все о документе находится в этой строке и относится к этому документу. Строки легко разделить, поэтому масштабировать проще.
Документно-ориентированные базы данных не отвергают концепцию отношений, они просто иногда позволяют приложениям разыменовать ссылки (CouchDB) или даже имеют прямую поддержку отношений между документами (MongoDB). Что еще более важно, DODB не имеют схемы. В табличных хранилищах это свойство может быть достигнуто со значительными накладными расходами (см. Ответ richardtallent), но здесь это делается более эффективно. При переходе с СУБД на DODB нам действительно следует научиться забывать о таблицах и думать о данных. Это то, что sheepsimulator называет подходом «снизу вверх». Это постоянно развивающаяся схема, а не предопределенная прокрустова кровать. Конечно, это не означает, что от схем следует полностью отказаться в любой форме. Ваше приложение должно интерпретировать данные,
В CouchDB, как и в Lotus Notes, вы действительно не должны думать о документе как о аналоге строки.
Вместо этого документ представляет собой отношение ( table).
В каждом документе есть несколько строк - значения полей:
ValueID(PK) Document ID(FK) Field Name Field Value
========================================================
92834756293 MyDocument First Name Richard
92834756294 MyDocument States Lived In TX
92834756295 MyDocument States Lived In KY
Каждое представление представляет собой запрос с перекрестной таблицей, который выбирает массивные UNION ALL для каждого документа.
Итак, он все еще реляционный, но не в самом интуитивном смысле и не в том смысле, который наиболее важен: хорошие практики управления данными.
, возможно, вам стоит прочитать это http://books.couchdb.org/relax/getting-started
Я только что слышал это, и это интересно, но понятия не имею, как реализовать это в реальном приложении;)
Вы можете попробовать получить копию firefox и firebug и поиграть с функциями map и reduce в javascript. они на самом деле довольно крутые и забавные, и, кажется, являются основой того, как добиться чего-то в CouchDB
, вот небольшая статья Джоэла на эту тему: http://www.joelonsoftware.com/items/2006 /08/01.html[1277 visible