Diskuze: ERP systém

Tvůrce

Zobrazeno 27 zpráv z 27.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
Mně jde hlavně o tu funkčnost je to primárně:
<ul>
<li>evidence objednávek</li>
<li>Spravování produktů a kategorií</li>
<li>Faktury</li>
<li>Správa zákazníků</li>
<li>Statistiky prodejů</li>
<li>evidence skladu</li>
</ul>
Napadlo mě vytvoření nějakého API možnost komunikace s E-shopem, nebo
třeba naprogramovat tam i shell.
Samozřejmě je podporována správce rolí a práv.
Další věci mě moc nenapadají co by to mohlo umět
Pokud je rozhraním internetový prohlížeč, tak je to v pořádku. Základem je dobrá databáze. Kterou sis vybral? MariaDB, SQLite nebo PosgreSQL?
Mohu jen souhlasit s Kitem, informační systémy jsou hlavně o datech, chce to hlavně dobře navrhnout databázi. Dále samozřejmě používat v PHPčku MVC architekturu, ideálně nějaký framework.
To cachování si dobře rozmysli. Většinou není potřebné, neboť to řeší už MySQL.
Zálohování MySQL se řeší dumpem a následnou kompresí. Jiný způsob nedoporučuji.
Se zaváděním ERP systému mam tu zkušenost, že čím více se něco programuje či konfiguruje tím déle to celé trvá a tím méně spolehlivě to nakonec funguje.
Tím nechci nikoho odradit od programování.
Jenom se divim, že to při dnešní široké dostupnosti systémů ještě
někdo takhle dělá.
Může se zeptat, který existující ERP systém se Vám líbí a proč?
Občas o ERP píši zde: http://www.vaclavkeil.cz/erp-novinky/
Jestli nemáš ani uživatelskou zkušenost s ERP, tak si můžeš pro lepší představu zdarma stáhnout nějakou trial verzi (např. mě teď napadá, že ABRA by měla mít ke stažení + i nějaké online demo... +i další by měli mít třeba aspoň online demo/trial, tušim, že Helios či Algotech na vyžádání z těch působících na našem trhu...)
Problém je v tom, že ta dostupná dema ERP jsou děsně přeplácána zbytečnými vlastnostmi. jan.vencl asi chce něco jednoduchého, proto si to chce udělat sám. V těch nabízených ERP se inspirace hledá těžko.
Podle mne při návrhu není špatné vyjít z vlastních tabulek excelovského typu. Sice dá trochu práci je normalizovat, ale výsledek je většinou použitelnější než u dostupných ERP.
Souhlasím, že v tomto případě (nejenom) tyhle demo nabízí zbytečnou funkcionalitu, na druhou stránku mohou poskytnout prvotní představu a také, jak jsou některé věci či postupy řešeny (např. co by asi tak měly/mohly určité tabulky obsahovat a jak udělat návaznost mězi jednotlivými kroky/funkcemi).
Ono ještě před vytvářením nějakého datového modelu (např. za využití tabulek excelovského typu) by nebylo od věci si udělat alespoň hrubý procesní model firmy, z kterého by se při tvorbě datového modelu vycházelo (aby nedošlo k podstatnému opomenutí nějaké entity nebo také k případné eliminaci nepodstatného, aneb jak si psal o Occamově břitvě)
Děkuju zarady, nicméně možná jsem malinko přecenil svoje schopnosti. Přečetl jsem si seriál o MVC redakčním systému na jeho základě si nejdříve napíšu tedy vlastní framework(to se hodí vždycky), ano je jich tu mnoho dalších, nicméně mít něco vlastního je dle mého naázoru vždy lepší. O každém řádku vím vše. Chápu postup atd... to jsou ty výhody:) je to běh na dlouho trať ale bude to příjemná cesta jak se něco naučit a pokud výsledkem bude použitelná aplikace tak to bude Epic Win.
ERP nemusí být složité. Zkus pro tuto chvíli dát bokem technickou realizaci a začni projektovat. Vem si kus papíru a začni dávat dohromady:
Teprve potom si vyber vhodnou databázi (MySQL není úplně špatná volba) a vhodné programovací jazyky (klidně pro každou oblast jiný). Základem je správná struktura databáze. Pozdější změny jsou sice možné, ale většinou se pak musí řešit příliš mnoho závislostí.
Pro popis se obvykle používá UML, ale pro tvoji potřebu to není nezbytně nutné. Ale je to vhodné.
Spíš relačně. Objektových databází moc není a naroubovat objektový program na relační databázi není zrovna triviální úloha.
Právě u takových systémů se to s tou objektovostí nesmí přehnat, jinak skončíš u nějakého ORM frameworku.
Právě proto bys měl začít diagramem užití a diagramem tříd. To je objektová záležitost. Diagram aktivit už bude navazovat na relační model.
Když se ORM používá správně, tak na něm není nic špatného. Pokud ORM používat nebude, nebude to s tou objektovostí tak horké.
Pokud by se používala správná databáze, tak by ORM vůbec nebylo potřebné. Dokonce i databáze DB4 má v PHP přímočaré použití v objektech, bez nutnosti ORM.
ORM je zlo.
Sám používám relační databázi (PostgreSQL) a ORM framework. Jsem s tím maximálně spokojen. Taky jsem si myslel, že to bude těžké skloubit dohromady, abych využíval plně (nebo alespoň efektivně) oba koncepty, ale je opravdu radost s tím teď pracovat.
V tom případě nevyužíváš výhod relačních databází, ale degraduješ ji na úložiště.
Na druhou stranu má PostgreSQL spoustu NoSQL vlastností.
V podstatě jo. Snažím se používat triggery, pohledy, vytvářet databázové funkce apod. Ale celkem velkou část logiky mám v databázi a dost mi to tak vyhovuje.
EDIT: Na PostgreSQL teď přecházím z MySQL, tak je jasné, že nevyužívám všechno, co ta databáze nabízí, protože s ní prostě zatím neumím, ale už se mi dost líbí. Dokonce bych ji i doporučil na ten ERP systém. Jenom kdyby byla trochu víc rozšířená a byla v nabídce víc webhostingů.
PostgreSQL se na webhosting moc nehodí. Na tak primitivní použití se z SQL databází nejlépe asi SQLite. Nejen kvůli výkonu, ale nabízí i funkčnost, kterou MySQL ani PostgreSql nabídnout nemohou.
Pro náročný webhosting, na kterém se velmi často mění data (např. interaktivní hry), bych určitě použil databázi Redis. Skoro bych ji označil jako objektovou databázi, v MVC v podstatě nahradí model. Aplikace je pak mnohem jednodušší a také svižnější, utáhne víc uživatelů.
Zobrazeno 27 zpráv z 27.