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

[Storm 31 009]

спс, воспользуюсь советом в следующий раз

Не за что, просто реально, иногда пишешь модуль под бешеную загрузку, стресс-тестируешь его, все ок, сдаешь.

А потом там нагрузка в 50 раз меньше - но, блин, это не твои половые проблемы, что заказчик так и не развил бизнес, как хотел.

 

Ты-то причем, если в корень взять ?

 

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

Ммм .. комбинированный ключ такого рода тебе зачем ?

Ключ - это тупо АйДи, неважно, как он сложен и из каких полей.

ИТ в другой таблице должен быть точно такой же АйДи, чтобы связать эти обе таблицы.

Комбинированный ключ отличается от "обычного" тем, что в нем "АйДи" формируется путем вычисления по какому-то алгоритму (хеш, шмешь и т.д.) из НЕСКОЛЬКИХ полей таблицы.

[Bublik 16 095]

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

[Storm 31 009]

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

Клиника, че - какой Кодд, какой Том, какой ПК, какой орел

 

стараюсь рассматривать базу чем проще - тем лучше.

Так надо рассматривать ВСЕ, даже жизнь.

Оно надежнее и понятнее.

Edited 31.05.2016 05:58 by Storm

[Bublik 16 095]

Шторм, а аутерджойны часто надо было делать?

[Storm 31 009]

Шторм, а аутерджойны часто надо было делать?

Ну, по обстоятельствам

Обычно этот предикат вообще пропускается в большинстве СУБД

 

А так да, конечно - джойны нашефсе

[shumbola 871]

Ну, по обстоятельствам

Обычно этот предикат вообще пропускается в большинстве СУБД

 

А так да, конечно - джойны нашефсе

Ну вот, пиши еще вуалируя свое незнание за ненормальным написанием терминов.

 

Хинт: join predicate

 

Еще раз, пиши нормально, лом или нет. Или переходи в личку.

[Storm 31 009]

Шумбола, пошел на хрен - так понятно ?

 

Извини, в истинном значении нельзя написать.

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

 

Ты за предикат хочешь что-то сказать и за чистоту понятий применительно к SQL ?

Тогда да, предикат есть выражение, где на выходе мы имеем ложь, истину или ХЗ ака анноун.

Оутер тогда просто служебное слово.

А так им можно обозвать и суть того, о чем писал Бублик - это не должно быть поводом для "пошел в личку !"

[shumbola 871]

Storm,

 

Ну какой-же ты модератор, если сам нарушаешь правила?

 

Я хочу, чтобы писали нормально. Чтобы и другим участникам было удобно. Иначе, в личку. Так и правила требует.

 

Если бы нормально писал, думаю, что не получилось бы то, что у тебя получилось.

[Storm 31 009]

Я хочу, чтобы писали нормально. Чтобы и другим участникам было удобно. Иначе, в личку. Так и правила требует.

Я уважаю твое желание, нет вопросов.

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

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

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

[Bublik 16 095]

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

 

Шторм, а как ты видишь, скажем, такой запрос: у тебя есть три таблицы. таблица наименований товара. таблица серий-партий товара. таблица прихода расхода (в данном контексте расхода).

 

у серии фк это наименование товара. у таблицы расхода - фк это серия товара.

 

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

 

я знаю как это сделать явой, но это не совсем скл стайл будет.

[Storm 31 009]

у тебя есть три таблицы.

Тут уже придется кодить )), к вящей радости Шумболы.

таблица наименований товара - Product

таблица серий-партий товара - ProductP (Parties)

таблица прихода расхода (в данном контексте расхода) - ProductIncInvDet (Income Invoice detail)

Select Product.ProductName, count(1)

from Product

Left join ProductP on ProductP.ProductId = Product.ProductId

Left join ProductIncInvDet on ProductIncInvDet.PartlNo = ProductP.PartNo

where ProductIncInvDet.Date between DtFrom and DtTo

and ProductIncInvDet.Sign = "Sale"

group by Product.ProductId order by count(1) DESC

 

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

ABC анализ хотят делать чта ль ?

ну, топ 20-тка и т.д.

 

АПД: Добавил проверку на признак продажи

 

Учи БД и скуль, Бублик. Они несложные. а профиту дают кучу.

Edited 02.06.2016 10:56 by Storm

[shumbola 871]

Я уважаю твое желание, нет вопросов.

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

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

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

Молодец, что выше написал нормально (ну почти). Переключение раскладки - ничтожна по сравнению с тем что набираешь. В итоге, делаешь удобно не только для себя но и для остальных участников. В том числе и для Bublik. ;-)

 

Насчет правил, ничего я тебе показывать не буду. Ты и сам найдешь/знаешь. Речь не про Inner или outer было, речь было про predicate.

[Storm 31 009]

Шумбола, если что-то не нравится - лес - там.

Уясни это при общении со мной, большая личная просьба.

 

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

Тогда, там выше, еще раз прочитай, куда надо идти.

Что-то можешь лучше - пиши тут, мы хоть поучимся.

А пока игнор.

Edited 02.06.2016 10:44 by Storm

[Sirinius 20 386]

всё же понятно, нафиг на латинице писать специально, если того не треба?

[Storm 31 009]

всё же понятно, нафиг на латинице писать специально, если того не треба?

Чел ратует за чистоту языка и понятийной терминологии SQL, в чистом незамутненном виде.

Напрочь позабыв, что ни одна боевая система не будет успешно работать в третьей нормальной форме ))

При этом ничего полезного от него за все время в теме не появилось.

Edited 02.06.2016 11:31 by Storm

[Bublik 16 095]

Да ты верно говоришь топ 20 и т.п. ) да блин придется по ходу скуль копать. вообще типовое приложение - это по ходу 80% скуля, 10% бэкэнда в виде явы и 10% фронта. )) (в некоторых случаях 15%) жизнь - боль.

[Storm 31 009]

вообще типовое приложение - это по ходу 80% скуля, 10% бэкэнда в виде явы и 10% фронта. )) (в некоторых случаях 15%) жизнь - боль.

Золотые слова, Бублик.

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

 

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

Так оно логичнее, но дороже.

Edited 02.06.2016 12:24 by Storm

[Bublik 16 095]

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

 

просто сейчас мода на ОРМы и но-скл )) но в носкл я вообще дуб. а по ормам - их проблема в том, что я уже начал думать ормами. )

Edited 03.06.2016 20:26 by Bublik

[Storm 31 009]

но в носкл я вообще дуб

Мода пройдет, он займет свою нишу, небольшую, но займет

[Bublik 16 095]

Шторм, а вот такой вопрос - допустим, у тебя есть некая таблица. там приход расход товара. в ней же есть цена прихода этого товара и цена отпуска этого товара, ну и количество конечно же. так же есть фк на справочник партий товаров.

 

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

 

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

[Storm 31 009]

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

Да, конечно, более того. можно еще кучу вещей мимоходом посчитать.

 

могу сделать явой. а вот скл? и вообще, резонность этого есть? т.е. где лучше.

В данном случае надо спускать все на уровень БД.

 

Вообще, есть золотое правило - все, что можно спустить на БД - спускаем на БД.

БД с данными работает куда лучше, быстрее и оптимальнее, экономя твое процессорное время, память, код, траффик БД-АппСервер и т.д.

[Bublik 16 095]

эээ а зачем тогда вообще что то кроме бд и скл нужно? Шторм, а такой отчет как примерно выглядеть будет? Много строк? просто я это на яве вижу как выгрузка таблицы далее выборка-подборка итерациями. или одной итерацией.

[alexforce2 383]

эээ а зачем тогда вообще что то кроме бд и скл нужно?

Нужна же "прокладка" между юзером и БД и удобство) А так да, можно и через консоль вставлять, забирать данные тз БД

Edited 06.06.2016 16:04 by alexforce2

[Storm 31 009]

эээ а зачем тогда вообще что то кроме бд и скл нужно?

Качественная визуализация результатов, удобный интерфейс и т.д.

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

Та же ява в связке с ораклом предполагает различное программирование модулей, пакетов, для управления какими-то внешними объектами, либо вот да, осуществления некой прокладочной функции между СУБД и клиентом.

 

Шторм, а такой отчет как примерно выглядеть будет? Много строк?

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

[Bublik 16 095]

Черт знает, я его лично не пользовал, я сом-коннектор юзал, суть дела одна - обращение к объектам 1С на языке 1С и получение необходимых тебе выборок.

В обратную сторону, т.е. вставку в 1С - пока не делал, но, думаю, эта возможность так же точно есть.

Лучче где-нить в отдельной теме обсудить.

по кому не знаю но вебсервисы. он же рест (вроде как - там черт ногу сломит, но точно рядом) это когда ты запросы из базы делаешь в форме урла типа somehost/good/get - он тебе вернет объектом список всех товаров somehost/good/get/instock - всех товаров на складе /somehost/good/get/3 - вернет только детальные данные о товаре с айдишкой три /somehost/good/delete/99 - удалит товар с айди 99 -- ну в общем как то так. (либо без гет пост пут делет - это будет от типа метода зависеть каким обращаешься) и список всех этих "команд" если 1с их дает хорошо было б знать чтоб можно было что-то свое сделать. как то так.. т.е. "языка" 1с там по-идее нет. вернее есть, но уже на уровне сервера 1са слоем ниже.