Струва ли си MySQL?
54 отговора
4841 прегледа
като пари де).А кат си помислиш ква е цената на MS SQL-a тръпоки те полазват.Пък и е толкова тежка работата с него че напрао страшно.Ама всичко зависи за какво ти трябва де.Re: Струва ли си MySQL?
Йееееееееееп.А такааааааааа. Стана тя какавато станаааааааааа.
Та значи според мен едва ли има нещо по-тежко от Oracle-то. Сигурно работи супер, мноо екстри, върха ,ама мнооого тежко бреееееее. А MS SQL по скромничко, пък кат се замислим за качеството на майкрософтскте продуктиииииииииии.
Тва всичко си е майтап де.
Та значи според мен едва ли има нещо по-тежко от Oracle-то. Сигурно работи супер, мноо екстри, върха ,ама мнооого тежко бреееееее. А MS SQL по скромничко, пък кат се замислим за качеството на майкрософтскте продуктиииииииииии.
Тва всичко си е майтап де.
Re: Струва ли си MySQL?
My SQL e super mente. Nesto dori ne znam zasto ima SQL w imeto kato ne poddryja normalni tranzakcii. I niam i flojenie selcet-i. Abe goliam prostotia. Zaebi go. Wypreki che MySQL e free pak e super mente w srawnne na MS SQL (wypreki che e na MS). Abe dori Access poddryja tranzakcii be. Prosto niamam dumi!
в отговор на RepeatableRead
#8
Re: Струва ли си MySQL?
Е кое е лошотото като не потдържа вложени селекти бре??? Самия SQL от последните години изклучва такива.Още повече че всеки курс за оптимизация на SQL заявките за почва с думите: "Никога, ама никога не използвайте вложен селект, ако искате се изпълнява бързо" Леле пък ако вложения селект е върху същата таблица няма да казвам какво става.В крайна сметка господ за целта ни е дал JOIN-a.
А по въпроса за транзакциите.И мен тва мноо ме мъчи и много псувам по въпроса.Обаче хората мноооого ясно са си казали че НЕслучайно няма транзакции, просто са приели друг подход за заключвания и въстановяване (който още не съм го усетил) и здраве и живот в следващата версия ще ни зарадват с поддръжката на транзакции.
А по въпроса за транзакциите.И мен тва мноо ме мъчи и много псувам по въпроса.Обаче хората мноооого ясно са си казали че НЕслучайно няма транзакции, просто са приели друг подход за заключвания и въстановяване (който още не съм го усетил) и здраве и живот в следващата версия ще ни зарадват с поддръжката на транзакции.
Re: Струва ли си MySQL?
MS SQL познавам прекалено добре от ежедневната си работа вече повече от две години.
MySQL познавам много малко, най-вече от това което те казват за себе си. Аз го приемам това казване за истина.
Както би казал Salle, ами зависи.
MS SQL става за малки до средни проекти. Има доста развита функционалност, но има проблеми с бързодействието при сериозно натоварване, а също така надежността и сигурността му не са перфектни. Не става за големи проекти, които също така искат бързодействие.
MySQL има напълно умишлено някои ограничения.
Идеята им е, че управлението на една програмна система не трябва да се обляга на SQL сървъра, а на клиентската част или Middleware. С тази цел напълно умишлено няма тригери или съхранени процедури. С премахването на доста от тези, иначе нормални за един SQL сървар функции, те постигат завидно бързодействие.
Това го прави особено подходящ за приложения, при които има Middleware. Такива по подразбиране са WEB приложенията. Не случайно това е най-масовият сървър, използван за такива. Същевременно при тези приложения може да се получат и много големи натоварвания, при което се проявява и най-добрата му черта - бързодействието.
Финансовата разлика е малко по-трудно да се оцени. Аз по принцип съм на мнение, че ако не се работи в условията на изроден пазар, какъвто примерно е пазарът на софтуер в България, то изборът на сървър не трябва да се прави по финансови съображения, а по желана функционалност.
Горното за изродения пазар на софтуер в България /аз в момента не съм там/, във всички случаи не е по вина на страната или хората в нея. Просто повечето производители на софтуер явно не са чували за закона за търсенето и предлагането, и се опитват да продават продуктите си на цена, на която няма НИКАКВО търсене. Имайки предвид себестойността на повечето продукти, това е абсурд. MS SQL и за 100 лв. да го продават, пак ще са на печалба, но ... неведоми са пътищата Микрософтски. И не само Микрософтски.
Ако се върнем на техническата част, аз бих задал въпроса, струва ли си в сравнение, да речем с Postgres. Замислям се ... и не си променям отговора.
Не бих правил ERP система, използвайки MySQL.
MySQL познавам много малко, най-вече от това което те казват за себе си. Аз го приемам това казване за истина.
Както би казал Salle, ами зависи.
MS SQL става за малки до средни проекти. Има доста развита функционалност, но има проблеми с бързодействието при сериозно натоварване, а също така надежността и сигурността му не са перфектни. Не става за големи проекти, които също така искат бързодействие.
MySQL има напълно умишлено някои ограничения.
Идеята им е, че управлението на една програмна система не трябва да се обляга на SQL сървъра, а на клиентската част или Middleware. С тази цел напълно умишлено няма тригери или съхранени процедури. С премахването на доста от тези, иначе нормални за един SQL сървар функции, те постигат завидно бързодействие.
Това го прави особено подходящ за приложения, при които има Middleware. Такива по подразбиране са WEB приложенията. Не случайно това е най-масовият сървър, използван за такива. Същевременно при тези приложения може да се получат и много големи натоварвания, при което се проявява и най-добрата му черта - бързодействието.
Финансовата разлика е малко по-трудно да се оцени. Аз по принцип съм на мнение, че ако не се работи в условията на изроден пазар, какъвто примерно е пазарът на софтуер в България, то изборът на сървър не трябва да се прави по финансови съображения, а по желана функционалност.
Горното за изродения пазар на софтуер в България /аз в момента не съм там/, във всички случаи не е по вина на страната или хората в нея. Просто повечето производители на софтуер явно не са чували за закона за търсенето и предлагането, и се опитват да продават продуктите си на цена, на която няма НИКАКВО търсене. Имайки предвид себестойността на повечето продукти, това е абсурд. MS SQL и за 100 лв. да го продават, пак ще са на печалба, но ... неведоми са пътищата Микрософтски. И не само Микрософтски.
Ако се върнем на техническата част, аз бих задал въпроса, струва ли си в сравнение, да речем с Postgres. Замислям се ... и не си променям отговора.
Не бих правил ERP система, използвайки MySQL.
Re: Струва ли си MySQL?
По принцип, мнението ми е, че когато човек се занимава с бази данни, не трябва да се обвързва с конкретна реализация на БД. Работата трябва да се извършва чрез всеобщ унифициран интерфейс - ODBC, OLE DB, ADO и т.н. Въпросът ми има преди всичко финансов характер, дали недостатъците на безплатното могат да се преглътнат? Но така като гледам, явно не могат.
Не мога да разбера липсата на транзакции в MySQL, тя го прави излишен, ако си решил да си правиш релации. Въпреки това, може ли да се намери някой друг безплатен продукт, който обаче не отстъпва поне на MS SQL Svr. (за Oracle няма да говорим).
Я вышел им наперерез...
Не мога да разбера липсата на транзакции в MySQL, тя го прави излишен, ако си решил да си правиш релации. Въпреки това, може ли да се намери някой друг безплатен продукт, който обаче не отстъпва поне на MS SQL Svr. (за Oracle няма да говорим).
Я вышел им наперерез...
Re: Струва ли си MySQL?
Iavno niakoi te te izlagal che v MySQL ne migat da se organizirat tranzakcii, tova e pasaj ot MySQL Reference Manual for version 3.23.22 :
8.4 BDB or Berkeley_db tables
Berkeley DB ([линк]) has provided MySQL with a transaction safe table handler. This will survive crashes and also provides COMMIT and ROLLBACK on transactions. In order to build MySQL 3.23.x (BDB support first appeared in 3.23.15) with support for BDB tables ... .
taka che s malko nap6n, ako imash jelanie mojesh da imash i MySQL s tranzakcii
8.4 BDB or Berkeley_db tables
Berkeley DB ([линк]) has provided MySQL with a transaction safe table handler. This will survive crashes and also provides COMMIT and ROLLBACK on transactions. In order to build MySQL 3.23.x (BDB support first appeared in 3.23.15) with support for BDB tables ... .
taka che s malko nap6n, ako imash jelanie mojesh da imash i MySQL s tranzakcii
Re: Струва ли си MySQL?
За добро или лошо на практика няма начин да направиш универсално приложение, което да работи със всички SQL сървъри. Просто защото всеки SQL сървър си има свои специфични особености.
Поради това всеки опит за универасален интерфейс е обречен да съдържа орязан вариант на възможности. Иначе казано пресечното множество от това, което могат всички SQL сървъри. И съответно се губят силните страни на даден сървър, а те всичките си ги имат.
> липсата на транзакции в MySQL, тя го прави излишен, ако си решил да си правиш релации.
Ето това изречение звучи изключително странно.
Какво всъщност имаш предвид? Транзакциите нямат нищо общо с релационния модел. Или по-точно казано са надстройка на SQL сървърите върху RDBMS. Често операторите свързани с транзакциите се определят като DPL - Data Processing Language като добавка към първоначалните (по-скоро изначалните защото са дефинирани преди SQL) DDL и DML (Data Definition Language и Data Manipulation Language)
При всички положения опаче Релация (или "Отношение" както също се среща в българската терминология) в теорията се нарича това, което в практиката се нарича Таблица. т.е. всяка една таблица дефинира Релация или Отношение.
Транзакциите и като дефиниция и като смисъл и като реализация не са свързани с Релациите.
Транзакция означава поредица от действия които се извръшват "атомарно" т.е. или всички се завършват докрай или всички се отхвърлят до началното състояние. С други думи в резултат от Транзакция системата може да премине н едно и само едно ново състояние или да остане в състоянието преди началото на транзакцията.
Фактът, че на практика транзакции се реализират предимно във SQL сървърите, може да се разглежда малко или много като необходима случайност
това обаче не променя коренно различния характер на двете неща. Ако не друго можеш да реализираш транзакции върху да кажем Обектно Ориентирана База данни например.
Колкото до това има или няма транзакции във MySQL виж clubs.dir.bg/showthreaded.php?Cat=8&Board=database&Number=1937492298&page=0&view=collapsed&sb=5&part=
Linux is like a wigwam - No Windows, No Gates, Apache inside
Поради това всеки опит за универасален интерфейс е обречен да съдържа орязан вариант на възможности. Иначе казано пресечното множество от това, което могат всички SQL сървъри. И съответно се губят силните страни на даден сървър, а те всичките си ги имат.
> липсата на транзакции в MySQL, тя го прави излишен, ако си решил да си правиш релации.
Ето това изречение звучи изключително странно.
Какво всъщност имаш предвид? Транзакциите нямат нищо общо с релационния модел. Или по-точно казано са надстройка на SQL сървърите върху RDBMS. Често операторите свързани с транзакциите се определят като DPL - Data Processing Language като добавка към първоначалните (по-скоро изначалните защото са дефинирани преди SQL) DDL и DML (Data Definition Language и Data Manipulation Language)
При всички положения опаче Релация (или "Отношение" както също се среща в българската терминология) в теорията се нарича това, което в практиката се нарича Таблица. т.е. всяка една таблица дефинира Релация или Отношение.
Транзакциите и като дефиниция и като смисъл и като реализация не са свързани с Релациите.
Транзакция означава поредица от действия които се извръшват "атомарно" т.е. или всички се завършват докрай или всички се отхвърлят до началното състояние. С други думи в резултат от Транзакция системата може да премине н едно и само едно ново състояние или да остане в състоянието преди началото на транзакцията.
Фактът, че на практика транзакции се реализират предимно във SQL сървърите, може да се разглежда малко или много като необходима случайност
това обаче не променя коренно различния характер на двете неща. Ако не друго можеш да реализираш транзакции върху да кажем Обектно Ориентирана База данни например.
Колкото до това има или няма транзакции във MySQL виж clubs.dir.bg/showthreaded.php?Cat=8&Board=database&Number=1937492298&page=0&view=collapsed&sb=5&part=
Linux is like a wigwam - No Windows, No Gates, Apache inside
Re: Струва ли си MySQL?
Ми поне 99% от работата си я върши чистия SQL, така че не виждам какво пречи да се ползва ODBC. Освен това, в ODBC-то си имаше или функция за извличане на всички поддържани от сървъра неща, или за проверка дали се поддържа конкретно нещо. Може и двете да ги има. Например, суфтуерът ти са му нужни транзакции - просто правиш проверка и готово, няма нужда да се връзваш към конкретна база, за която си сигурен, че поддържа транзакции.
Колкото до релациите - аз влагам малко по-разширен смисъл в тях. Представи си числово id в някоя таблица, на което отговарят много записи в друга. Там, обаче, id-то не е числово, ами е стринг, или пак число, но образувано според някаква сложна логика. Очевидно, че без транзакции няма да ти е сигурна обработката.
Я вышел им наперерез...
Освен това, в ODBC-то си имаше или функция за извличане на всички поддържани от сървъра неща, или за проверка дали се поддържа конкретно нещо. Може и двете да ги има. Например, суфтуерът ти са му нужни транзакции - просто правиш проверка и готово, няма нужда да се връзваш към конкретна база, за която си сигурен, че поддържа транзакции.
Колкото до релациите - аз влагам малко по-разширен смисъл в тях. Представи си числово id в някоя таблица, на което отговарят много записи в друга. Там, обаче, id-то не е числово, ами е стринг, или пак число, но образувано според някаква сложна логика. Очевидно, че без транзакции няма да ти е сигурна обработката.
Я вышел им наперерез...
Re: Струва ли си MySQL?
Spored men zawisi wyrhu kakyw proekt raboti6. Az rabotq predimno s SQL Server i moga da poso4a edno golqmo predimstwo - ne ti e neobhodim administrator koito denono6tno da poddyrva bazata. Drugo predimstwo e ulesneniq interfeis - po-golqmata 4ast ot funkcionalnostta ima i GUI, koeto dosta ulesnqwa i predimno uskorqwa administriraneto...
za mySQL moga da kava 4e predimstwoto mu nai-we4e e cenata. Byrzodeistwieto sy6to e pljus, no ako se stigne do razmeri i natowarenost kogato mySQL 6te prewyzhovda MS SQL Server, bih kazal 4e e proekta e stanal prekaleno ma6taben za da se raz4ita na mySQL i nqkolko stotin (ewentualno hilqdi) dolara za drug db server we4e nqmat zna4enie...
Ta ideqta mi e 4e ako nqma da e ne6to mnogo golqmo i iziskwa6to mnogo poddryvka, go ahead s mySQL (ima si orkaround za wsqko ne6to koeto mu lipswa, samo trqbwa da se potrudi6). W protiwen slu4ai MS SQL bi bil moq izbor...
za mySQL moga da kava 4e predimstwoto mu nai-we4e e cenata. Byrzodeistwieto sy6to e pljus, no ako se stigne do razmeri i natowarenost kogato mySQL 6te prewyzhovda MS SQL Server, bih kazal 4e e proekta e stanal prekaleno ma6taben za da se raz4ita na mySQL i nqkolko stotin (ewentualno hilqdi) dolara za drug db server we4e nqmat zna4enie...
Ta ideqta mi e 4e ako nqma da e ne6to mnogo golqmo i iziskwa6to mnogo poddryvka, go ahead s mySQL (ima si orkaround za wsqko ne6to koeto mu lipswa, samo trqbwa da se potrudi6). W protiwen slu4ai MS SQL bi bil moq izbor...