Всё что написанно верно. Но. Глубина абстракций очень высока.
Сомневаюсь что это помогает в понимании реального проектирования БД.
Ну например вот это:
Отношение находится в НФБК, когда каждая нетривиальная и неприводимая слева функциональная зависимость обладает потенциальным ключом в качестве детерминанта.
Это же мозг разрывает :)
А пример вообще опасный, так как ваш Composite Key [Тариф+Время Начала] во второй таблице нарвётся на ограничение уникальности.
WITH CTE AS (
SELECT 1 as n
UNION ALL
SELECT n+1
FROM CTE
WHERE n < 8
)
SELECT A.n as 'A', B.n as 'B', C.n as 'C', D.n as 'D', E.n as 'E', F.n as 'F', G.n as 'G', H.n as 'H'
FROM CTE AS A
CROSS JOIN CTE AS B
CROSS JOIN CTE AS C
CROSS JOIN CTE AS D
CROSS JOIN CTE AS E
CROSS JOIN CTE AS F
CROSS JOIN CTE AS G
CROSS JOIN CTE AS H
WHERE A.n NOT IN (B.n,C.n,D.n,E.n,F.n,G.n,H.n,B.n+1,C.n+2,D.n+3,E.n+4,F.n+5,G.n+6,H.n+7,B.n-1,C.n-2,D.n-3,E.n-4,F.n-5,G.n-6,H.n-7)
AND B.n NOT IN (C.n,D.n,E.n,F.n,G.n,H.n,C.n+1,D.n+2,E.n+3,F.n+4,G.n+5,H.n+6,C.n-1,D.n-2,E.n-3,F.n-4,G.n-5,H.n-6)
AND C.n NOT IN (D.n,E.n,F.n,G.n,H.n,D.n+1,E.n+2,F.n+3,G.n+4,H.n+5,D.n-1,E.n-2,F.n-3,G.n-4,H.n-5)
AND D.n NOT IN (E.n,F.n,G.n,H.n,E.n+1,F.n+2,G.n+3,H.n+4,E.n-1,F.n-2,G.n-3,H.n-4)
AND E.n NOT IN (F.n,G.n,H.n,F.n+1,G.n+2,H.n+3,F.n-1,G.n-2,H.n-3)
AND F.n NOT IN (G.n,H.n,G.n+1,H.n+2,G.n-1,H.n-2)
AND G.n NOT IN (H.n,H.n+1,H.n-1)
ORDER BY A.n,B.n,C.n,D.n,E.n,F.n,G.n
А как Relaxed Co-Scheduling вписывается в эту картину?
Насколько я понимаю теперь в ESXi нету ограничений на то что все vCPU/worlds одной VM должны выполняться в том же таймслоте?
Так всё таки надо делить на 100.
Значене "\Process(application_name)\% Processor time" отдается счётчиком в процентах.
Ведь умножаете на 0.7 а не на 70%.
Насколько я вижу вы хотите посчитать какой процент времени программа работает в режиме User Mode.
Допустим что "\Process(application_name)\% Processor time" показывает только User Mode, хотя я неуверен.
Тогда математика была-бы такой:
("\Process(application_name)\% Processor time" * "\Processor(_Total)\% User time") / 100
И потом эту цифру ещё предполагается поделить на колличество ядер.
Поправте меня пожалуйста но ведь Hyper-V не является бесплатной. Нужна Datacentrer для того чтобы воспользоваться всеми вышеперечисленными фичами, не так ли? То есть для каждого физического сервера по $5000.
Представляете куда съезжает среднее значение когда у вас тысяча единичек и только несколько больших цифр.
А для контроля версий можно использовать "Redgate SQL Compare". Софтик умеет сравнивать базу данных с например TFS.
Сомневаюсь что это помогает в понимании реального проектирования БД.
Ну например вот это:
Это же мозг разрывает :)
А пример вообще опасный, так как ваш Composite Key [Тариф+Время Начала] во второй таблице нарвётся на ограничение уникальности.
Совсем неудевительно что у людей возникают трудности в понимании :) Это-ж надо умудриться так сложно написать про простые вещи.
Теперь ясней понимаю как размер NONCLUSTERED INDEX зависит от того какой тип данных выбран для CLUSTERED INDEX.
Я думаю вместо Value надо поставить А?
Насколько я понимаю теперь в ESXi нету ограничений на то что все vCPU/worlds одной VM должны выполняться в том же таймслоте?
Значене "\Process(application_name)\% Processor time" отдается счётчиком в процентах.
Ведь умножаете на 0.7 а не на 70%.
Насколько я вижу вы хотите посчитать какой процент времени программа работает в режиме User Mode.
Допустим что "\Process(application_name)\% Processor time" показывает только User Mode, хотя я неуверен.
Тогда математика была-бы такой:
("\Process(application_name)\% Processor time" * "\Processor(_Total)\% User time") / 100
И потом эту цифру ещё предполагается поделить на колличество ядер.
Так? или я что-то путаю?
или моральные проблемы создания искусственного интеллекта
А здесь http://tuxmobil.org/phones_linux_sms.html я думаю желающие себе что нибудь найдут.