Na tohle je možné mít právě takový pohled, že se jedná o dva hovory, které spolu souvisí. První hovor k nám na ústřednu a druhý z ústředny na telefon. Každý hovor má svůj SIP CALLID a svůj RTP stream i svoji SIP signalizaci, která je naprosto oddělena od toho druhého hovoru. Používá se jistý hlasový kodek. Pozor jak volající tak volaný mohou nezávisle na sobě hovory přepojovat, kdy možnost to celé zaznamenat jako jediný hovor by selhala!xtonda píše:Ano, pokud je to už tak nešikovně navrženo, že u každého hovoru je pouze jeden příznak in/out/redirect, tak zdvojení řádků je hack, kterým lze hovor, který začíná i končí u Odoriku, vyřešit bez změny struktury databáze, ale logicky správně mi to rozhodně nepřipadá, jeden hovor je prostě stále jeden hovor.
A co třeba když někdo volá na něčí číslo 800, může být žádoucí účtovat dvě různé ceny. Jinou volajícímu i volanému i když obě čísla jsou v síti.
API položku redirection_parent_id vrací již dlouho. (dva roky?) http://www.odorik.cz/w/api:calls#historie_hovoru Dokonce se jmenuje stejně, jak jste navrhoval. Pravda z dokumentace to nešlo vyčíst, bylo třeba si to vyzkoušet. Dnes jsme přidali příklad, co to může vrátit, z kterého by to mělo být jasné. Myslím ale, že tohle zatím nefunguje u hovorů spojených přes callback nebo přes čísla 822.xtonda píše: A i kdybych přistoupil na to, že se pracuje s půlhovory, tedy že se samostatně zaznamenávají originace a samostatně terminace, tak je problém, že z není jednoduše a jednoznačně (a to ani z API) poznat, které dva řádky jsou opačné konce jednoho hovoru, chybí tam něco jako to redirection_parent_id, zdroj a cíl je sice stejný, ale to nestačí a časy se liší, musel bych složitě odhadovat kdy to ještě může patřit k sobě a kdy to už mohou být těsně následující hovory.
Poučky je v každém případě dobré znát a umět databázi navrhnout i s nimi, když to má význam - většinou ano.xtonda píše: To jestli ty poučky platí je relativní, já bych spíš řekl, že platí, ale že někdy existuje rozumný důvod je porušit, ovšem abych to mohl kvalifikovaně posoudit a rozhodnout, tak je musím znát a být si vědom i důsledků jejich porušení.
Běžná data, jako zásoby skladu, účetní položky a pod, nebobtnají do takových rozměrů jako u nás, aby hrozilo ucpání databáze a přehlednost a integrita dat je na prvním místě.
Ne vždy je to ale nejlepší.
Co se týče historie hovorů, je tam jedno specifikum. To specifikum spočívá v tom, že historie hovorů je svým způsobem logování. Nikdy se nebude měnit, vždy z dané tabulky budeme jen číst nebo přidávat nové záznamy. Prostě se jen jednou zapíše a hotovo. A občas zopakovat nějakou tu informaci v logu, už není žádný zásadní prohřešek.
A co více, ještě tabulku replikujeme do jiných databází, abychom nezamykali a nezatěžovali hlavní databázi v případě déle trvajícího dotazu. Tedy opět stejná informace na více místech, dokonce vyloženě záměrně... Koncový uživatel nic nepozná.
. Samozřejmě kompletní výpis je úžasný pro debugování atd, často jej používám. Ale přimlouval bych se za další opravdu jednoduchý výpis, který bych mohl ukázat zbytku rodiny, kde by byl jeden hovor v rámci jedné linky reprezentován právě jedním řádkem. Pěkný nový rok.