СУБД и Базы Данных, OLTP, OLAP, BI

[Bublik 15 993]

вторая тупойская загадка.. ну это думаю все ответят:

 

 

 

Комната кубической формы сторона ребра 3 метра в каждом углу сидит по мухе (всего три), они взлетают, какова вероятность что в полете они окажутся в одной плоскости?

 

и третья: для тебя специально Шторм:

 

есть четыре сущности:

репорт, репортхедер, репорколамнс, ленгвидж.

 

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

 

причем связи в контексте ПК-ФК.

Edited 30.05.2016 14:02 by Bublik

[Storm 31 009]

и третья: для тебя специально Шторм:

Заптра или вечером. Пора в зал

[Storm 31 009]

репорт, репортхедер, репорколамнс, ленгвидж.

 

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

 

причем связи в контексте ПК-ФК.

 

Репорт:

ПК: РепортИд,

ФК: РепортТайпИд, ЛангвиджИд

 

Хедер:

ПК:ХедерИд,

ФК: РепортТайпИд, ЛенгвиджИд - обеспечивается вариативность Хедера от типа репорта и лангвиджИд, единственно, надо добавить поля ДатаФром и ДатаТо, иначе связка РепортТайпИд+ЛангвиджИд будет уникальной, т.е. одному епортайпу и лангвиджиду будет обязан соответствовать единственный такой же ключ в Хидере, если историю изменений и предварительные занесения вести не планируется, то и пох, тогда к Репорт- у вяжем непосредственно по ХидерИд, т.е. в репорте появляется ФК: ХидерИд.

В случае с датами - связка идет по РепортТайпИд+ЛангвиджИд+ дата формирования между ДатаФром и еслинулл(ДатаТо, "21000101") - но лучше сразу по умолчанию ставить ДатаТо = 21000101

 

Аналогично с коламнс.

 

Лангвидж - чиста справочник

ПК: ЛангвиджИд

бла-бла-бла

 

РепортТайп - чиста справочник

ПК: РепортТайпИд

бла-бла-бла

 

146%

Шайтан ! Откуда знаешь ?

 

Если в третью нормальную форму все тащить, ну, типа идеально по науке, чтаб все тормозило )),

то хидеры и коламнсы вяжутся исключительно к лангвиджу, создается доптаблица связки хидерид-репорттайп, назовем ее ХидерТайп и доптаблица КоламнсТайп такая же для коламнсов, там и ДатаФром и ДатаТо, а в таблу репортсов уже прокидывается исключительно ключ ХидеТйапИд и КоламнсТайпИд .

Edited 30.05.2016 16:30 by Storm

[shumbola 871]

Bublik, Storm

 

[CENSORED], это что у вас за язык такой? Нормально написать (на любом из языков) не судьба?

[Storm 31 009]

Нормально написать

 

лом.

[shumbola 871]

лом.

Не верю, скорее всего не сможешь. :-)

[Bublik 15 993]

Я тебя почти понял )) Такой вопрос.. ты бы в какой нибудь из этих сущностей комбинированный ключ использовал бы?

[Storm 31 009]

Не верю, скорее всего не сможешь. :-)

Толсто и глупо

 

ты бы в какой нибудь из этих сущностей комбинированный ключ использовал бы?

Ну вот в первом только варианте, когда хидер и коламнс вяжес с репортом по РепортТайп+ЛангвиджИд, т.е. ключ идет комбинированный ФК_Хидер_Репорт(РепортТайп, лангвиджИд) и такой же точно в Репорт-е - ФК_Репорт_Хидер(РепортТайп,ЛангвиджИд), так же коламнс.

Насколько второй вариант лучше первого - все зависит от частоты обновления хидеров и количества строк в таблицах + частоты запросов.

[Bublik 15 993]

стоп. я так понимаю комбинированный ключ это когда два фк и нет пк в сущности. верно?

[Storm 31 009]

стоп. я так понимаю комбинированный ключ это когда два фк и нет пк в сущности. верно?

Да, точнее, когда ПК может и быть, но он не участвует, т.е. на него похрен.

 

Комбинированный ключ может содержать и ПК при плохом раскладе, ну, когда проектировщик ака архитектор был в отпуске

[shumbola 871]

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

[Bublik 15 993]

нет. это вырвимозгная задача потому что когда я сказал по первому варианту Шторма (где без комб-ключа), мне сказали что это ужасный дизайн, и надо КК и ПК не нужен в какой то из сущностей, в какой правда, не помню.

[Storm 31 009]

нет. это вырвимозгная задача потому что когда я сказал по первому варианту Шторма (где без комб-ключа), мне сказали что это ужасный дизайн, и надо КК и ПК не нужен в какой то из сущностей, в какой правда, не помню.

Я тему создам сейчас туда все перенесем и атм продолжим.

Вкратце, ПК нужен от слова всегда - ибо некоторые БД после занесения двух одинаовых строк не дадут ничего потом с ними сделать - ни апдейтить, ни удалить, т.к. ои не понимают. каую именно надо изменить )

Это мс скуль, например, по дефолту, даже 2012.

 

В твом случае, Бублик, уникальность сочетания РепортТайпИд+ЛангвиджИд даст для Хидерса как раз первичный ключ, без проблем . Но можно и использовать просто сиквенс .

 

Создал тему:

http://www.tforum.uz/topic/33780-%d1%81%d1%83%d0%b1%d0%b4-%d0%b8-%d0%b1%d0%b0%d0%b7%d1%8b-%d0%b4%d0%b0%d0%bd%d0%bd%d1%8b%d1%85-oltp-olap-bi/

 

Ща будем просить туда все перенести.

[alexforce2 383]

Было бы интересно почитать полезную(именно то, что можно применить и применяется на практике в сфере big data) информацию по данной теме от спецов со стажем.

 

Видимо я кого-то не спросил ))

Да нет, просто увидел весьма специфичную тему(с пустым первым постом), но при этом, в некотором роде обобщённую, если судить по перечисленным тэгам, поэтому и пришла в голову мысль, что ТС ошибся форумом.

[Bublik 15 993]

Шторм, если у тебя есть ПК накой тебе комбинированный ФК? Ладно, скажу, у меня было самое дибильное собеседование по тому, что снизу в моей подписи написано. Хибер позволяет использовать комбинированный ключь. НО. у меня возникает вопрос в реальной нужности этого. т.е. ту базу я расписал примерно как и ты без всяких комби-ключей, да и в моем понимании эти ключи в том контексте не нужны. (если есть пк). да и геморроя с ними больше чем пользы.

 

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

 

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

Edited 30.05.2016 18:50 by Bublik

[Storm 31 009]

и можно дергать сущности без пк.

Пусть они построят рабочую систему на сущностях без ПК, а потом отойдут в сторонку и засекут время.

Неважн, что это будет - ПК, ЮК и т.д., БД должна однозначно идентифицировать запись.

Будет сдвойка - будет двойка.

 

Было бы интересно почитать полезную(именно то, что можно применить и применяется на практике в сфере big data) информацию по данной теме от спецов со стажем.

Да мы с Бубликом наоффтопили, завтра перенесем.

Вы где с биг дата сталкивались ?

 

НО. у меня возникает вопрос в реальной нужности этого.

Абсолютно монопенисуально, в конкретно твоем случае никакого выигрыша этот комбинированный ключ не даст, а местами даже мы сильно проиграем на джойнах.

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

Но ! Для OLTP систем, кои и предполагались в условии, неявно, но так.

Edited 30.05.2016 19:39 by Storm

[alexforce2 383]

Вы где с биг дата сталкивались ?

В том то и дело - что нигде на практике не сталкивался, много видел в вакансиях(вэб-разработка, в основном на cерверах MySQL, PostgreSQL) данное требование, подобного опыта у меня нет, поэтому с удовольствием почитал бы.

Edited 31.05.2016 02:18 by alexforce2

[Storm 31 009]

вэб-разработка, в основном на cерверах MySQL, PostgreSQL

И разработчику надо какое-то знание биг даты ?

Это все новомодные понты, типа, модно требовать.

Слишком уж большая эта область

 

А почитать по биг дате на русском не припомню, а на английском есть Кимбел вроде, но, может уже и его перевод есть.

Это фундаментальное.

Есть еще много разных направлений, у Микрософта оно называется BI, так же у SAP и Oracle.

[alexforce2 383]

Серверному разработчику в большом проекте, конечно, не надо знать биг дата на уровне админа(или архитектора, не знаю как правильно) БД, но иметь, хотя бы, поверхностные знания в данном вопросе будет плюсом

[Storm 31 009]

Серверному разработчику в большом проекте

Не серверный, а обычный веб-разработчик серверной части приложения, или backend-разработчик.

 

Естественно, в любом проекте крайне необходимо общее понимание того, с чем работаешь.

И если ты очень-очень близко связан с извлечением/изменением данных в БД, и эта БД относится к биг дате, то да, тебе надо знать общие понятия.

Но у меня большой скептицизм в плане того, что кто-то будет ваять свои механизмы работы с БД в случае с биг датой - это будет реальный найтмар, поэтому-то все и пользуются имеющимися средствами визуализации от известных компаний.

[Bublik 15 993]

Серверному разработчику в большом проекте, конечно, не надо знать биг дата на уровне админа(или архитектора, не знаю как правильно) БД, но иметь, хотя бы, поверхностные знания в данном вопросе будет плюсом

для начала что такое биг дата. у меня были собесы где высокомерно меня спрашивали "а вы работали с бигдатой?"

[Storm 31 009]

для начала что такое биг дата. у меня были собесы где высокомерно меня спрашивали "а вы работали с бигдатой?"

Дибилы. Что именно они хотели услышать ?

Типа, да, я обрабатывал 5 миллиардов строк ?

[Bublik 15 993]

Дибилы. Что именно они хотели услышать ?

Типа, да, я обрабатывал 5 миллиардов строк ?

ну как пример, я писал софт один аптечный. как оно есть по честноку им работает человек 20ть если одновременно. ну вот собес значит. меня спрашивают шаблонные вопросы. бла бла. короче, на всё отвечаю. (это по яве). далее вопрос типа расскажите про последний проект. рассказываю бла бла. вопрос сколько работает человек? я в районе 20-ти. и тут я даже ушами слышу их кисляк на роже типа фууу. у нас всё что меньше 200-т считается маленьким. в итоге фидбэк - вы владеете предметом но в активе у вас незначительные проекты с незначительной нагрузкой. Надо было как лев толстой тереть что не 20 а 200, и вообще всё умножать на 10 или 100 - всё было бы путём. а как проверишь? ну хотят вот люди чтоб всё было биг. и дата биг. и лоадаут биг и команда биг. и вообще всё.

[Storm 31 009]

Говори им, что нагрузочное тестирование проводилось из расчета работы 200-т пользователей одновременно.

[Bublik 15 993]

Говори им, что нагрузочное тестирование проводилось из расчета работы 200-т пользователей одновременно.

у апачтомката кстати, потолок по умолчанию 200 потоков (грубо говоря двести одновременных реквест/респонсов), и 10 000 сессий. т.е. на 200 реальных одновременных запросов они предполагают 10000 пользователей. т.е. говоря 20 - можно подразумевать реальную 1000. :) но для сурьезных посонов это такие пустяки. от 10000 и выше. )) спс, воспользуюсь советом в следующий раз

 

вопрос по базе такой.. у меня есть некая запись, в ней 1пк и скажем, 2-3-4 фк с других таблиц. я могу называть эти 2-3-4 фк комбинированным ключом?

Edited 31.05.2016 05:23 by Bublik