SaaS / SaaS: 2.6 - Models, Databases and ActiveRecord

Любое отклонение от этого нам нужно будет обрабатывать по собственному разумению. Кроме того,

maxwell44 02.03.12 в 22:35

в реляционной БД каждый должен иметь некоторое уникальное значение для идентификации,

maxwell44 02.03.12 в 22:36

которое Rails зовёт первичным ключём и согласно конвенции Rails это целое число, которое называется ID.

maxwell44 02.03.12 в 22:38

Вообще вы не должны иметь с ним дела, потому что Rails будет

maxwell44 02.03.12 в 22:39

автоматически создавать и присваивать новые ID за вас, но знайте, что они есть.

maxwell44 02.03.12 в 22:40

Так что на практике вас будет очень редко заботить, какой ID у фильма.

maxwell44 02.03.12 в 22:40

Вся информация о фильме, имеющая значение, находится в других столбцах,

maxwell44 02.03.12 в 22:41

но вам нужно иметь способ уникальным образом ссылаться на него в случае, например, если есть совпадения в других столбцах.

maxwell44 02.03.12 в 22:43

Вот что делает ID. Окей. Так, ещё разок,

maxwell44 02.03.12 в 22:43

это может быть один из тех пяти процентов, в теперешней терминологии.

maxwell44 02.03.12 в 22:45

Но так как архитектура касается альтернатив, когда бы я ни говорил о пути, каким это сделано в Rails,

maxwell44 02.03.12 в 22:49

или о пути, каким это сделано в SaaS, вы должны немедленно подумать:

maxwell44 02.03.12 в 22:49

ну, а какими другими путями это может быть сделано? Какие альтернативы остались у таблиц?

maxwell44 02.03.12 в 22:50

И есть изрядное число аргументов за и против паттерна ActiveRecord.

maxwell44 02.03.12 в 22:53

О, простите, я должен указать, что схема, вообще говоря, -

maxwell44 02.03.12 в 22:56

это набор всех таблиц в данной БД и структура, которой они обладают.

maxwell44 02.03.12 в 22:56

Так что если Вы видите слово схема вы знаете что это значит. А если мы не будем

husband 03.03.12 в 14:58

использовать ActiveRecord, а как вы знаете, каждая модель знает как CRUD себя?

husband 03.03.12 в 15:03

Это не кажется чем-то очевидным? Как ещё вы могли бы это сделать?

maxwell44 05.03.12 в 18:58

Ну, есть другой путь, по которому вы могли пойти. Я подобрал извращённую версию UML,

maxwell44 05.03.12 в 19:03

унифицированного языка моделирования, которую мы коротко рассмотрим,

maxwell44 05.03.12 в 19:04

чтобы попытаться проиллюстрировать разницу между ActiveRecord и Data Mapper,

maxwell44 05.03.12 в 19:13

который является другим распространённым способом сделать то же. Итак, идея вот в чём. Это кажется тривиальным, но в ActiveRecord мы просто говорим:

maxwell44 05.03.12 в 19:15

О, у нас есть две модели, фильм и зритель,

maxwell44 05.03.12 в 19:18

и каждая модель построена на представлении, что нам не нужно делать ничего в коде нашего приложения

maxwell44 05.03.12 в 19:18

для взаимодействия с БД при реализации четырёх CRUD-операций. В то время как в паттерне Data Mapper

maxwell44 05.03.12 в 19:21

для каждой модели, которую мы создаём,

maxwell44 05.03.12 в 19:26

мы также должны установить Mapper, которому даны инструкции о том,

maxwell44 05.03.12 в 19:27

как выполнять CRUD-операции для моделей того или иного типа. И фактически, в то время как ActiveRecord довольно сильно

maxwell44 05.03.12 в 19:29

привязан к выполнению поверх реляционной БД, о которых мы вскоре поговорим подробнее,

maxwell44 05.03.12 в 19:30

Data Mapper может работать практически с чем угодно. Итак, вы можете спросить:

maxwell44 05.03.12 в 19:31

Ну, почему бы вы захотели выбрать тот или иной способ? Одна причина -

maxwell44 05.03.12 в 19:32

это, как мы упомянули несколько минут назад, то, что реляционные БД очень тяжело

maxwell44 05.03.12 в 19:34

масштабировать, особенно по прошествии определённой точки. Но есть множество механизмов хранения,

maxwell44 05.03.12 в 19:35

которые не являются реляционными и которые крайне хорошо масштабируются. Так что есть некоторая выгода

maxwell44 05.03.12 в 19:37

от структурирования ваших данных таким образом, чтобы вы могли использовать такие нижележащие механизмы хранения.

maxwell44 05.03.12 в 19:37

И в действительности, так поступает Google App Engine. Если вы пишете приложение, которое выполняется на Google App Engine,

maxwell44 05.03.12 в 19:41

в общем случае вы не можете писать запросы к реляционной БД.

maxwell44 05.03.12 в 19:41

Используя некоторые уловки и некоторые интересные особенности, которые там есть, вы можете сделать что-то,

maxwell44 05.03.12 в 19:45

что выглядело бы похоже в некоторых простых случаях. Но вообще говоря, вы не можете.

maxwell44 05.03.12 в 19:46

Всего несколько минут назад мы видели, что модели могут взаимодействовать между собой.

maxwell44 05.03.12 в 19:49

Например, рецензия может быть отобрана, будучи привязанной к отдельному фильму

maxwell44 05.03.12 в 19:58

или же к человеку, написавшему её. Или, если вы собирались сделать систему голосования за фильмы,

maxwell44 05.03.12 в 20:00

то вы можете вообразить, что фильм имеет кучу разных ранжирований

maxwell44 05.03.12 в 20:04

и каждое ранжирование привязано к этому фильму, но к отдельному пользователю, верно?

maxwell44 05.03.12 в 20:05

Так что там будут отношения вида один к одному, многие к одному, многие ко многим. Как мы увидим,

maxwell44 05.03.12 в 20:06