Как стать автором
Обновить
0
0
vovik99 @vovik99

Пользователь

Отправить сообщение
Ваша реализация SLA принципиально противоречит SRE.

Это нормально, и даже хорошо, когда методологии не следуют слепо, а адаптируют к реалиям. Очевидно, что для кого-то такой SLA нужен и полезен. Но если бы в статье была небольшая ремарка, что речь идет не о классическом SLA в понимании SRE, а о каком-то кастомном (или из другой методологии) решении, более подходящем к данному случаю — читающим было бы гораздо понятнее.

Я уже не в первый раз вижу/слышу такое понимание SLA (именно с точки зрения SRE), где речь идет о SLO для внешних клиентов. Сначала казалось, что люди просто не в теме. После еще нескольких повторов уже стало казаться, что это я что-то путаю. В этот раз я еще раз перечитал, что же написано в SRE. И SLA там все же про последствия и ответственность, а не про внешних клиентов.
Использование методологии ITIL в качестве первоисточника знаний о SRE, скажем так, несколько странный подход. Может быть лучше прочитать SRE Book? Там SLA вводится так:
Agreements

Finally, SLAs are service level agreements: an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain. The consequences are most easily recognized when they are financial—a rebate or a penalty—but they can take other forms. An easy way to tell the difference between an SLO and an SLA is to ask «what happens if the SLOs aren’t met?»: if there is no explicit consequence, then you are almost certainly looking at an SLO.16


И еще сноска, которая под номером 16:
16Most people really mean SLO when they say «SLA.» One giveaway: if somebody talks about an «SLA violation,» they are almost always talking about a missed SLO. A real SLA violation might trigger a court case for breach of contract.


Вы можете с этим не соглашаться, но тогда у вас в статье не SLA в понимании SRE, а что-то другое.
Примеры SLA: сервис доступен 99,95% времени в течение года; 99 критических тикетов техподдержки будет закрыто в течение трёх часов за квартал; 85% запросов получат ответы в течение 1,5 секунд каждый месяц.

Это все же примеры SLO, а не SLA. Примером SLA было бы кто кому и сколько платит за нарушение вышеуказанных метрик.
Я вообще-то никаких определений не давал. Только описал максимально краткую суть 2НФ, чтобы показать некомпетентность статьи автора. Строгое определение, естественно, гораздо подробнее и приведено в вышеупомянутых пруфах.

Страна, зависящая от города в таблице магазинов, является транзитивной зависимостью страны от первичного ключа. При этом поле от первичного ключа, тем не менее, зависит. В таком виде таблица не соответствует 3НФ, но находится в полном согласии с 2НФ.

Не готов здесь проводить ликбез по нормальным формам, тут нужна отдельная хорошая статья. Но исходный материал точно таким не является :)
Определение Вы нашли, но, похоже, не потрудились все же его понять.

Во всех перечисленных пруфах при определении 2НФ явно идет речь о составном ключе. Если первичный ключ состоит из одного поля (и таблица в 1НФ), то она уже автоматически находится в 2НФ.

Если поле не зависит ни от какой части ПК, то это уже не называется отношением, не является реляционной моделью данных и никакие нормальные формы тут не применимы.
У автора — определенно ерунда.

Да и Вам было бы полезно найти четкое определение 2НФ, понять его, потом уже комментировать. Без обид, но тут нет ничего, с чем можно соглашаться или нет. Все очевидно.
Про 2НФ написано нечто, абсолютно к ней не относящееся. Вторая нормальная форма — это когда нет полей, зависящих только от части составного ПК.

Не знаю уж, оригинал это такой или последствия перевода. Но в любом случае, если бы переводчик был в теме — такого появиться не должно было бы. Переводить материал про НФ, не разбираюсь в них — сложно ожидать хорошего результата.
Попробую развить мысль. Если рассуждать подобным образом, то получится, что любую БД можно представить в виде одной таблицы.
Вот такие будут поля:
ObjectName - имя объекта
FieldName - имя свойства
Value - значение. Будет строковое, т.к. к строке можно привести любой тип.

В такой модели ровно те же плюсы, что и в предложенной для связей:
* Любые объекты можно добавлять произвольно, не перепроектируя БД
* Любые свойства тоже можно добавлять ничего не перепроектируя

Да и недостатки те же, ну, подумаешь, огромная таблица. Подумаешь, чуть сложнее запросы. Если где начнет тормозить - всегда можно выделить отдельную табличку для какого-нибудь конкретного объекта.

Уж не знаю, каким паттерном это назвать, но никому не кажется, что такой подход несколько ... эээ ... странный?

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность