Licencne podmienky MS SQL Server 2012 Express edition

[Daniel_Andrascik]

Zdravim Vas chalani.

Chcel by som sa opytat v kratkosti na licencne podmienky MS SQL Server 2012 Express edition. Microsoft vehementne uvadza na svojej stranke ze tato edicia je free (s limitom velkosti databazoveho suboru do 10GB). Je to naozaj tak? Moze sa pouzivat v sietovom prostredi komercne i nekomercne? Ma nejake obmedzenia na pocet pripojenych klientov atd? Chcem sa touto cestou opytat vas este pred tym ako sa zacnem borit v oficialnych licencnych podmienkach, ktorym aj tak skoro nikto nerozumie...

Dik...

[Mi.Chal.]

Ty omezení jsou akorát technická ( typu počet cpu, velikost db, využitelná paměť). V naší aplikaci mssql express používáme taky. Asi u MS spoléhají na to, že pro větší provoz budou ty omezení tak limitující, že si zákazník koupí nějakou placenou verzi.

Jinak prakticky pokud bys porušil licenci, tak se těžko můžeš obhajovat tím, že někdo na cizím fóru něco napsal a schválil ti to.

[Daniel_Andrascik]

Of course. Zatial ziadnu komercnu aplikaciu s MSSQL nenasadzujem, ale zvazujem to. Toto robim tuna skor ako pociatocny prieskum. Faktom ostava ze obmedzenia expres edicie su pre mna zatial tak vzdialene ze doposial by ma v ziadnom uz aplikovanom projekte neobmedzili a zatial ani narocnejsi projekt planovany nemam.

Snad mi nejaku relevantnu info poskytne Radek Cervinka ktory pod touto DB vyvyja svoj soft CRMplus

[Radek Červinka]

Není to můj SW. Volba MS SQL nebyla má a nejsem z ni uplne stastny.
Licence je slozita a do budoucnosti zvazujeme pouziti jine DB prave k vuli licencnim podminkam. Pro normálního uživatele je to jedno, ale jsou tam takové háčky, že třeba nesmíš nabízet zákazníkovi hosting jeho DB na svojem serveru (express edice). Myslím jen ze MS SQL 2008 SP2 má v licenci omylem nejakou vyjimku, která je volnější. Nejsem si jist zda dokonce by si nemel zakaznik SQL server instalovat sam, jen mu  nabídnout balíček (ale tím si nejsem jist - instalace není moje část).

Kdyz k tomu připočtu vubec problémy s instalacemi, definivní zavislost na MS serveru (to mne vyloženě sere) atd.

Na druhou stranu je to relativne kvalitni SQL databáze...

[Daniel_Andrascik]

Vdaka za odpoved. Vzhladom na to ze je to free edicia asi sa budem len tazko dozadovat nejakych informacii na nejakom ceskoslovenskom supporte, ak vobec taky existuje. Takze mi neostava nic ine len si z instalacky vytiahnut a prelozit podrobne licencne ujednanie.

Nejsem si jist zda dokonce by si nemel zakaznik SQL server instalovat sam, jen mu  nabídnout balíček (ale tím si nejsem jist - instalace není moje část).

A co ked zakaznikovy dodavam nejaky micro server na mieru, pripadne len obycajne pecko ktore mu cele instalujem aj s oknami a aj s DB?? To zacina byt zaujimave.

[Radek Červinka]

On to nikdo nebude asi řešit, než tvůj SW začne být slavný :-)

[Daniel_Andrascik]

V tom pripade by som bol asi zahojeny, pretoze ja robim vyhradne jednoucelove zakazkove softveri ktore dokonca vacsinou bezia maximalne len na vnutropodnikovej sieti v jednom objekte

[Radek Červinka]

A co budes do te DB ukladat? Priklad

[Daniel_Andrascik]

Vetsinou bud historicke technologicke data, alebo rozne udaje o produktivite vyroby, pripadne rozne merania atd. Ja viem, toto by zvladol aj SQLite, a aj to zvladal, dokial sme nepotrebovali multi-user pripojenia. Pre MSSQL sme sa rozhodli pretoze je v priemysle velmi etablovany a nezriedka ho uz zakaznici dokonca prevadzkuju. Vtedy uz licencie ani riesit nemusime, len nam pridelia DB

[Radek Červinka]

Tady bych určitě uvažoval o něčem co bude moc běžet na něčem jiném než MS. Ale to je muj nazor.

[Daniel_Andrascik]

Hmm, uz hned v prvom prispevku si sa vyjadril ze nie si moc z MSSQL stastny. Mohol by si to zlahka opysat? Kludne si rad precitam aj subjektivny nazor, nemusis tento server hodnotit objektivne. Popravde si este pre interne potreby firmy vyvyjame vlastny ERP system na ktory by sme tiez chceli pouzit MSSQL.

[Radek Červinka]

Ty jsi v jine situaci, delate si vlastni ERP.

Nasi zakaznici casto maji ve firme linux server se kterym jsou spokojeni a maji ho vyuzit treba z 10%, a tezko se jim vysvetluje ze musi mit jeste jeden PC, aby u nich mohlo bezet CRMplus jen k vuli MS SQL. Takový zákazník pak často raději koupí něco jiného.
A bezet MS SQL ve virtualce je problem, jelikoz podle toho co se zkouselo a co jsem cetl je ve virtualce SQL server dost pomalejsi. No a hostovani nabizet nemuzes, protoze ta palka za serverovy MS SQL (aby to bylo licencne OK) je pro nasi cilovou skupinu celkem vyrazna.

Navic cokoliv co k tomu chces pripojit (napr. web frontend) musi byt schopno s MS SQL komunikovat, tj. budto to bezi na MS OS nebo to musis nejak prekladat treba pres REST. I kdyz treba FireDAC umi k MS SQL pristupovat i z Linuxu nebo Macu.

Navic jednu dobu byla myslenka jednouzivatelského systemu (nyni z toho zustalo jen CRMfree), ale chtel jsem aby se to dalo jen zkopirovat a bezet, treba jak to umi FireBird nebo Interbase. Ne, proste u MS SQL musis dodat 50MB balik, ktery se musi instalovat do systemu protoze MS to proste nezvlada. Obecne se mi uz nekolikrat overilo, ze prilisne spolehani na MS se proste nevyplací. Takze momentalne hledame rozumny SQL server. Ale možná z toho nic taky nebude. Zatím se nerozhodlo.

Minuly tyden mi bylo receno, ze celý systém drah v Kazachstánu se opírá o InterBase a vzhledem k tomu v jakem je stavu tamější infrastruktura (elektro, net) to zvládá bez ztráty kytičky, což o něčem svědčí.

Ale toto jsou nase problemy, ktere se tebe, ktery mas vlastni ERP pro interni pouziti netykají.

[pf1957]

Obecne se mi uz nekolikrat overilo, ze prilisne spolehani na MS se proste nevyplací.

Podle me klicove pro rozhodnuti jsou dve veci:

1. jak pise Radek: licence, platformy, skalovatelnost  (co budu s aplikaci delat, az mi prestane platforma PC stacit a budu muset na nejake vykonejsi zelezo a OS atd.)
2. Sql jazyk u MSSQL IMHO vypada, jako kdyz pejsek s kocickou pekli dort tj., coz temer znemoznuje port na cokoli/ z cehokoli jineho. Takze jak jednou zvolis MSSQL jsi v koncich - vcetne platformy.

Jinak je to asi jedno: kazdy RDBMS ma svoje specifika, se kterymi je treba se vyporadat a nektera dost cloveka zaskoci, protoze by je nepredpokladal.


Pokud to charakter aplikace dovoli, drzel bych se nejakeho ORM, ktery sice ma radu omezeni, ale setre mi rozdil mezi ruznymi RDBMS a defacto mi dovoli aplikaci migrovat zmenou konfiguraku, kde se mu predepise jina DB. Dnes uz i pro Delphi existuje tusim Hibernate a komercni Aurelius a mozna jeste neco - nesleduju, protoze jsme si kdysi vyvinuli vlastni. A kdyz ne ORM, tak bych se snazil s tim zachazet tak, aby se dal pouzit i jiny RDBMS nebo aspon aby jeho zmena nebyl neprekonatelny problem.

Pokud je treba sahnout po triggerech a SP, zajistit integritu i kdyz se v tom budou hrabat  cizi aplikace apod., pak bych osobne vybiral ze dvou free reseni:
1. Firebird
2. PostgreSQL

Firebird je urcite spolehliva RDBMS, ktera leccos zvladne a z pohledu programatora se tam slusne pracuje s triggery a SP, ale co by delala pod opravdu velkou zatezi nevim.
PostgreSQL patri naopak do rodiny velkych DB, ktery pri prvnim dojmu pusobi trochu tezkopadneji podobne jako DB/2, ale s rostouci zatezi nejde do kolen.

[Daniel_Andrascik]

Mockrat diky za vase vyjadrenia. Vyber spravnej DB je vzdy pre kazdeho vyvojara a vyvojarsky tym celkom slusna seansa. Oboznamit sa s ponukou, porovnat si pre a proti, ujasnit si vlastne potreby, ujasnit co je dolezite a co nie. Platene neplatene systemy, treba, alebo netreba aj embeded, podora OS a potom aj samotne features jednotlivych DB. Je toho plna prdel a tiez uz to zvazujem hodne dlho. Vyber je pomaly tak isto narocny, ako ked si rodina dva roky vybera auto ktore si za tazko usetrene peniaze chce kupit .

Radku, rozumiem tvojej problematike a ze za tym je to nestastne ukotvenie sa na MS OS a potom licencna politika. Na druhu stranu vsetky nase softy vo firme su tiez ukotvene na windowsoch. Ale priznam sa ze ked som pred dvomi rokmi objavil vas CRM system tak som bol hodne prekvapeny ked som zistil ze bezi na MSSQL. Hovoril som si: precoo?   

To pf:
No ta syntax u MSSQL je fakt unikatna  . Firebird a PostgreSQL som zvazoval tiez (a aj dalsie MySQL, resp. jej free alternativu MariaDB). U firebirdu je trapenie s dokumentaciou, Postgre je ako hovoris tazkopadne, ale hodnotim ho ako jedneho z najvhodnejsich kandidatov, len skoda ze nema embeded verziu (ale to nema ani MSSQL). Vyborne je tiez ze hosting MySQL (niekedy aj MariuDB) a PostgreSQL nie je problem zohnat aj u beznych webhostingovych spolocnosti.

Nad MSSQL uvazujeme preto ze ako hovorim v priemysle je casto nasadzovana. Mnoho priemyslenych SCADA systemov (ktore v drvivej vecsine bezia len na oknach) podporuje MSSQL a niektore iba MSSQL. Vo verzii 2012 zacal byt celkom zaujimavy aj variant LocalDB. Je to stale o dost horsie ako embeded varianty ostatnych SQL, ale uz sa to da nainstalovat paru kliknutiami "Next" "Next" "Next" a zabere to len nejakych 120MB co je pre vyvoj dost pohodlne a vraj to podla vyjadreni MS ma takmer zhodnu funkcionalitu ako riadny server. No ostavaju uz len tie licencne podmienky.

A ano ORM pouzivame aj ked vacsionu to kombinujeme s tym ze sem tam odpalujme vlasne dotazy. Ale vacsinou k tomu mam urobenu jednu triedu ktora operuje nad priamymi dotazmi nad DB. Cize pri zmene DB vacsinou by malo stacit prekonfigurovat ORM a prekopat tu jednu triedu.

V kazdom pripade, este raz vdaka za info. Budem dalej zvazovat ze co dalej. Minimalne to interne ERP nechame na MSSQL aspon koli skusenostiam a ostatne este zvazim.

[pf1957]

a aj dalsie MySQL, resp. jej free alternativu MariaDB).

Nad MySQL jsme udelali taky jednu aplikaci, kdyz to tenkrat licence umoznovala, ale ted uz jsem ji nezminoval, protoze neni Free a pak neni v podstate duvod o ni uvazovat, protoze IMHO jedinou jeji vyhodou je, ze ji znaji PHP strikaci. Jestli existuje nejaka rovnocenna free verze, tak by se asi o ni dalo uvazovat, i kdyz MySQL ve verzi 5.x mela nejake neprekonatelne prekazky v metadatech (zkousel jsem ji zaradit pod jeden evolucni system a tim, ze tam byla referencni integrita dobastlena az dodatecne, tak byl problem dostat se ke jmenum konstraintu nebo ceho a pak neco neslo programove dropnout a tim menit schema - detaily uz si nepamatuju)

U firebirdu je trapenie s dokumentaciou,

Tam to chce investovat do http://www.firebirdsql.org/en/books/ a koupit si IBExpert na udrzbu schematu a ladeni SP.

Postgre jsme v Jave pres Hibernate docela hodne zatezovali a nebyly s tim problemy.

ale to nema ani MSSQL

Ja bych rek, ze M$ ma neco, cemu rika Compact edition a to se mi zda, ze je nejaka ocesana embedded verze bez  triggeru, SP, jen v Unicode

[Mi.Chal.]

2. Sql jazyk u MSSQL IMHO vypada, jako kdyz pejsek s kocickou pekli dort tj., coz temer znemoznuje port na cokoli/ z cehokoli jineho. Takze jak jednou zvolis MSSQL jsi v koncich - vcetne platformy.

To platí obecně, existuje sice standard SQL, ale s tím se nic rozumného dělat nedá a v reálných aplikacích je vždycky potřeba použít věci, které jsou závislé na použité db.

Jinak je to asi jedno: kazdy RDBMS ma svoje specifika, se kterymi je treba se vyporadat a nektera dost cloveka zaskoci, protoze by je nepredpokladal.

Jeden kolega se tu snažil např. rozchodit připojení proti Oraclu. Narazili jsme na řadu takových featur, že se divím, že to vůbec někdo používá :-).

Pokud to charakter aplikace dovoli, drzel bych se nejakeho ORM, ktery sice ma radu omezeni, ale setre mi rozdil mezi ruznymi RDBMS a defacto mi dovoli aplikaci migrovat zmenou konfiguraku, kde se mu predepise jina DB. Dnes uz i pro Delphi existuje tusim Hibernate a komercni Aurelius a mozna jeste neco - nesleduju, protoze jsme si kdysi vyvinuli vlastni. A kdyz ne ORM, tak bych se snazil s tim zachazet tak, aby se dal pouzit i jiny RDBMS nebo aspon aby jeho zmena nebyl neprekonatelny problem.

Je to možnost jak vyřešit nějaké problémy, ale nové to zase přináší. Většinou ty ORM dělají věci, co člověk nepotřebuje, ale neumí věci, které potřebuje :-). Používali jsme nhibernate a jednak s tím byly výkonnostní problémy, druhak konkurenční.

[Daniel_Andrascik]

Nad MySQL jsme udelali taky jednu aplikaci, kdyz to tenkrat licence umoznovala, ale ted uz jsem ji nezminoval, protoze neni Free a pak neni v podstate duvod o ni uvazovat, protoze IMHO jedinou jeji vyhodou je, ze ji znaji PHP strikaci. Jestli existuje nejaka rovnocenna free verze, tak by se asi o ni dalo uvazovat, i kdyz MySQL ve verzi 5.x mela nejake neprekonatelne prekazky v metadatech (zkousel jsem ji zaradit pod jeden evolucni system a tim, ze tam byla referencni integrita dobastlena az dodatecne, tak byl problem dostat se ke jmenum konstraintu nebo ceho a pak neco neslo programove dropnout a tim menit schema - detaily uz si nepamatuju)

no inu MySQL je presne o tom, historicky velmi znama DB, hlavne vdaka webu. Mnohymi zatracovana a mnohymi zboznovana DB. Ale ano, nie je tak celkom free, kolem jej licencie je tiez polemika a malo komu je uplne jasne ako to je. MariaDB je jej alternativa. Je urobena takmer identicky, dokonca ma rovnake nazvy binarnych suborov. Appka ani nevie ze nefunguje na MySQL ale na marii. Skusal som ju len namatkovo a pri danych podmienkach bola o nieco pomalsia ako MySQL. Ale to mozno len preto pretoze som jej vykon nijako neladil. Proste som ju pouzival ako MySQL.

Ja bych rek, ze M$ ma neco, cemu rika Compact edition a to se mi zda, ze je nejaka ocesana embedded verze bez  triggeru, SP, jen v Unicode

Ten Compact edition u MSSQL existuje. Viem o nom, ale problem je s pristupom k nej. Nepamatam sa uz presne, ale mam pocit ze pristupit k nej z Delphi je problematicke a musi sa to riesit nejako oklukou. Ale embeded verzie DB maju vyznam len vtedy ak su pokial co mozno najidentickejsie so serverovou verziou. Inac potom je to skoro ako studium ineho DB serveru, no naco to je dobre.

Je to možnost jak vyřešit nějaké problémy, ale nové to zase přináší. Většinou ty ORM dělají věci, co člověk nepotřebuje, ale neumí věci, které potřebuje :-). Používali jsme nhibernate a jednak s tím byly výkonnostní problémy, druhak konkurenční.

Ano. Ja som pouzival zase TMS Aurelius a v niektorych momentoch som s nim dost bojoval. Preto niektore veci holt musim riesit priamo pomimo ORM. Nie je to teda ziadna vyhra, ale na pisanie vlastneho ORM, ktory by presne splnal vsetky moje potreby cas nemam. Vykon je samozrejme nizsi, o tom diskutovat nemusime, ale pre aplikacie ktore vyvyjam je dostacujuci.

[pf1957]

To platí obecně, existuje sice standard SQL, ale s tím se nic rozumného dělat nedá a v reálných aplikacích je vždycky potřeba použít věci, které jsou závislé na použité db.

To je pravda, ale u rady systemu se treba signatury SP podobaji, takze staci, kdyz vnitrek prepises treba uzitim kurzoru a zbytek zustane stejny vcetne volani z aplikace,
kdezto M$ pouziva obvyklou syntaxi jen pro funkce, pokud ta SP meni data, ma zcela odlisnou signaturu, kdyz to vraci tabulky, tak zase jinou a uz musis hrabat i do aplikace a nebo delat nejake ustupky (napr. M$ ma jine poradi parametru, takze nemuzes univerzalne predavat pozicne, jen jmenem, ale pro jmena si navic musis sahnout do DB pomoci Prepare) atd. Navic M$ chybi jeden typ triggeru a ty operace se tam delaji jinak atd.

Osobne z DB, do/z kterych jsem migroval, mi prijde  prechod do/z MSSQL zdaleka nejhorsi a nejpracnejsi.

Jeden kolega se tu snažil např. rozchodit připojení proti Oraclu. Narazili jsme na řadu takových featur, že se divím, že to vůbec někdo používá :-).

No, ja mu rikam pracovne č*rákl , ale na druhou stranu jsem ho videl v real time u telekomunistu a klobou dolu.

Je to možnost jak vyřešit nějaké problémy, ale nové to zase přináší. Většinou ty ORM dělají věci, co člověk nepotřebuje, ale neumí věci, které potřebuje :-).
Používali jsme nhibernate a jednak s tím byly výkonnostní problémy, druhak konkurenční.

O NHibernate jsem slysel, ze je to nepovedeny port, ale nikdy jsem s tim nic nedelal, jen s Hibernate. Ne, ze by me nezaskocila, ale zase ne natolik, abych poctive precetl http://www.manning.com/bauer2/ :-) Ale byl to web s billingem podle vyuzivanych sluzeb.

[pf1957]

Ale ano, nie je tak celkom free, kolem jej licencie je tiez polemika a malo komu je uplne jasne ako to je.

AFAIK, tak nejasnosti kolem licence skoncili, kdyz to koupil Oracle (http://www.mysql.com/about/legal/licensing/oem/)

OEMs (Original Equipment Manufacturers), ISVs (Independent Software Vendors), VARs (Value Added Resellers) and other distributors that combine and distribute commercially licensed software with MySQL software and do not wish to distribute the source code for the commercially licensed software under version 2 of the GNU General Public License (the "GPL") must enter into a commercial license agreement with Oracle.

[Daniel_Andrascik]

pekne...

Osobne z DB, do/z kterych jsem migroval, mi prijde  prechod do/z MSSQL zdaleka nejhorsi a nejpracnejsi.

Tomu hovorim uzitocna informacia aj ked je len subjektivna

[Radek Červinka]

No, ja mu rikam pracovne č*rákl , ale na druhou stranu jsem ho videl v real time u telekomunistu a klobou dolu.

Ha, kromě terminus "stříkač kódu" další perla :-)

Ono asi hodne znamená jak se to umí nastavit.

[Mi.Chal.]

No, ja mu rikam pracovne č*rákl , ale na druhou stranu jsem ho videl v real time u telekomunistu a klobou dolu.

Ha, kromě terminus "stříkač kódu" další perla :-)

Ono asi hodne znamená jak se to umí nastavit.

To není jenom o nastavení. Namátkou co si vzpomínám:

* z doslechu - Přičtení jednoho roku k datumu typu 29.2.2004 vygeneruje 29.2.2005, což skončí s chybou, protože to není platný datum
* názvy tabulek a sloupců jsou omezeny asi na 30 znaků. Měli jsme generované tabulky obsahující v názvech guidy, takže se to muselo celý předělat, protože to takový název ani nesežralo :-)
* umělci nerozlišují prázdný string a null. Pokud to chce člověk rozlišovat, tak si tu informaci o nullovosti asi musí nacpat do dalšího sloupce
* pak tam bylo něco z blobama. Jestli jsem to pochopil dobře, tak to nejde načíst najednou, ale jedním requestem se vrátí jenom délka dat v jednotlivých řádcích a pak se to musí číst znovu pro jednotlivé řádky