MySQL vs. InterBase
13 отговора
1496 прегледа
MySQL vs. InterBase
Може ли някой да каже нещо за сравнението между тия две СУБД? Знам, че принципно имат различно приложение, но ме интересува най-вече как се държат, като обслужват клиент-сървър приложения в локална мрежа. Щото аз най-спокойно си ползвах InterBase, но един познат ми се изсмя и взех да се замислям дали да не мина на нещо с повече перспектива (MySQL в случая). Предварително благодаря за отговорите!
Re: MySQL vs. InterBase
Interbase 7.x е доста сериозна база, а също и open-source проекта Firebird (който е клонинг от IB 6) и ако някой им се смее, просто не разбира от БД дизайн и програмиране (или най-малкото не е в час).
MySQL също е добра платформа, но както сам си забелязал, трудно е да се направи пряко сравнение - просто двете СУБД се използват за различни цели.
Mixy
MySQL също е добра платформа, но както сам си забелязал, трудно е да се направи пряко сравнение - просто двете СУБД се използват за различни цели.
Mixy
Re: Нещо не схващам ...
Явно смяташ, че целите не са различни и сравнение може да се направи. Защо не кажеш малко повече - точно такова мнение ме интересува. 
От моята практика (която всъщност не е много богата, понеже от 6-7 години вече не се занимавам активно с програмиране) съм забелязал, че MySQL се ползва повече като СУБД за уеб-програмиране, докато InterBase - за клиент-сървър приложения, работещи в локална мрежа/интранет. Доколкото мога да съдя от документацията, няма пречка всяка от двете СУБД да изпълнава и другата роля (може би все пак Интербейс ще има известни затруднения с платформите, но все пак има и файърбърд) , така че вероятно нещата са въпрос на личен избор и на популярност.
Вероятно греша някъде - наистина от години съм далеч от тия неща. Та затова питам тук.
От моята практика (която всъщност не е много богата, понеже от 6-7 години вече не се занимавам активно с програмиране) съм забелязал, че MySQL се ползва повече като СУБД за уеб-програмиране, докато InterBase - за клиент-сървър приложения, работещи в локална мрежа/интранет. Доколкото мога да съдя от документацията, няма пречка всяка от двете СУБД да изпълнава и другата роля (може би все пак Интербейс ще има известни затруднения с платформите, но все пак има и файърбърд) , така че вероятно нещата са въпрос на личен избор и на популярност.
Вероятно греша някъде - наистина от години съм далеч от тия неща. Та затова питам тук.
Re: Нещо не схващам ...
Личните ми впечатления от FireBird/Interbase 6:
Не лоша базичка да си правиш дипломната работа на нея (предимно за студенти от МЕИ/ТУ пишещи на Делфи). В реални условия за натоварена база - ужаз мизерия и кал по ушите. Гадна, бавна, трудна за настройване, дънеща се непрекъснато (като започнем от момента на рестартиране на машината и проблем с .GDB-тата и на фат 32), до скапване на транзакции, непълно записване / дублиране на данни и физическо саморазрушаване на таблиците !
Отвратителен мулти ленгуидж съпорт (пряко зависи от winбоза). Никакво описание и лесно управляем тунинг. Никакъв сериозен мониторинг на системата. Криво написан оптимизатор на заявки (ако има изобщо ;-)))) и т.н.
MySQL - използва се за web защото е ЛЕК и БЪРЗ (за разлика от предното). Във версиите които ползвам (3.23.хх)аз няма субселекти, сторнати процедури, тригери, не ползвам транзакции, ползвам MyISAM таблици точно заради двете думи които съм написал с главни букви. Работи ми перфектно с кирилицата и ми върши чудесна работа (разработвал съм не само web приложения на нея).
root@ro6avia#echo rm -rf * > /bin/seek_and_destroy
root@ro6avia#/bin/seek_and_destroy
Не лоша базичка да си правиш дипломната работа на нея (предимно за студенти от МЕИ/ТУ пишещи на Делфи). В реални условия за натоварена база - ужаз мизерия и кал по ушите. Гадна, бавна, трудна за настройване, дънеща се непрекъснато (като започнем от момента на рестартиране на машината и проблем с .GDB-тата и на фат 32), до скапване на транзакции, непълно записване / дублиране на данни и физическо саморазрушаване на таблиците !
Отвратителен мулти ленгуидж съпорт (пряко зависи от winбоза). Никакво описание и лесно управляем тунинг. Никакъв сериозен мониторинг на системата. Криво написан оптимизатор на заявки (ако има изобщо ;-)))) и т.н.
MySQL - използва се за web защото е ЛЕК и БЪРЗ (за разлика от предното). Във версиите които ползвам (3.23.хх)аз няма субселекти, сторнати процедури, тригери, не ползвам транзакции, ползвам MyISAM таблици точно заради двете думи които съм написал с главни букви. Работи ми перфектно с кирилицата и ми върши чудесна работа (разработвал съм не само web приложения на нея).
root@ro6avia#echo rm -rf * > /bin/seek_and_destroy
root@ro6avia#/bin/seek_and_destroy
Re: Защото ...
Не ме разбирай погрешно - далеч съм от мисълта да правя сравнения от типа "Кое е по-добро - Хари Потър или Властелинът на пръстените". Идеята ми беше някой, който има опит с MySQL, да сподели доколко тази СУБД се справя със задачите, поставени от едно клиент-сървър приложение в локална мрежа да речем. От отговорите съдя, че си се справя много добре, така че всъщност вече научих каквото ме интересуваше. 
Re: Нещо не схващам ...
> "трудно е да се направи пряко сравнение - просто двете СУБД се използват за различни цели."
Това пък откъде дойде?
Какво им е различно на "целите" и защо да е трудно да се прави пряко сравнение?
Ами както казах, трудно е, но не и невъзможно. Друг е въпроса, доколко ще е обективно.
Можеш да сравняваш базите по техн. спецификации - колко таблици и записи могат да имат, на какви машини (платформи) и колко транзакции за определено време могат да правят (синтетичен тест) и т.н. И двете бази се афишират като универсални, но няма универален алгоритъм, който да дава оптимални времена за работа при всякакви условия. Просто още не е измислен такъв. Дадена база може да се оптимизира да съхранява големи обеми информация, да е бърза в транзакциите или в какъвто друг аспект се сетиш. За това къде е най-добра говори най-вече сферата на приложение - MySQL се ползва най-често за web-приложения, а IB/FB за клиент/сървър в локални мрежи. Не, че обратното не е възможно - и двете бази го могат, но когато възникнат проблеми, решаването им може би е по-трудно. Например, по-трудно се намират ресурси за IB/FB когато се използва като решение за web. Докато за MySQL в комбинация с Linux, Apache и други технологии за web има предостатъчно информация.
Пробвай да сравняваш Ферари и Жигули комби - и двете могат да превозват товари и пътници от т. А до т. Б, но се сещаш, че при ферарито пътниците са ограничени до 2 (в масовите му версии :)) и е с малък багажник, докато Жигулито поема и пътници и товари в големи количества, но при доста по-ниски скорости и комфорт ...
P.S. Горния пример е доста груб и няма много общо с БД, но това се сетих - в момента само коли са ми в главата ... :))) Освен това, човека вече е направил своя (нов) избор, така, че дискусията приключва. Искрено му желая успех. Дано само някой не му се изсмее и за MySQL, докато си я ползва спокойно и щастливо, че пак ще трябва да сменя платформата :))) А смешници у нас колкото щеш ...
Mixy
Това пък откъде дойде?
Какво им е различно на "целите" и защо да е трудно да се прави пряко сравнение?
Ами както казах, трудно е, но не и невъзможно. Друг е въпроса, доколко ще е обективно.
Можеш да сравняваш базите по техн. спецификации - колко таблици и записи могат да имат, на какви машини (платформи) и колко транзакции за определено време могат да правят (синтетичен тест) и т.н. И двете бази се афишират като универсални, но няма универален алгоритъм, който да дава оптимални времена за работа при всякакви условия. Просто още не е измислен такъв. Дадена база може да се оптимизира да съхранява големи обеми информация, да е бърза в транзакциите или в какъвто друг аспект се сетиш. За това къде е най-добра говори най-вече сферата на приложение - MySQL се ползва най-често за web-приложения, а IB/FB за клиент/сървър в локални мрежи. Не, че обратното не е възможно - и двете бази го могат, но когато възникнат проблеми, решаването им може би е по-трудно. Например, по-трудно се намират ресурси за IB/FB когато се използва като решение за web. Докато за MySQL в комбинация с Linux, Apache и други технологии за web има предостатъчно информация.
Пробвай да сравняваш Ферари и Жигули комби - и двете могат да превозват товари и пътници от т. А до т. Б, но се сещаш, че при ферарито пътниците са ограничени до 2 (в масовите му версии :)) и е с малък багажник, докато Жигулито поема и пътници и товари в големи количества, но при доста по-ниски скорости и комфорт ...
P.S. Горния пример е доста груб и няма много общо с БД, но това се сетих - в момента само коли са ми в главата ... :))) Освен това, човека вече е направил своя (нов) избор, така, че дискусията приключва. Искрено му желая успех. Дано само някой не му се изсмее и за MySQL, докато си я ползва спокойно и щастливо, че пак ще трябва да сменя платформата :))) А смешници у нас колкото щеш ...
Mixy
Re: MySQL vs. InterBase
>--------
но един познат ми се изсмя и взех да се замислям дали да не мина на нещо с повече перспектива (MySQL в случая).
<------
MySQL не е конкурент на Interbase/Firebird, тъй като и липсват
доста неща (хората преди мен ги казаха). Ползва се основно във Web-програмирането, с което май се изчерпва сферата и на действие.
тука:
[линк]
има описания на някои "сладки" (в големи кавички) неща, които ще
направят работата ви с MySQL да не е прекалено лека ;)
Ще цитирам само едно:
1.14 February 31st
Throughout history many different calendar systems have been developed around the world. Although the way of counting years still varies, most countries and regions have adopted the Roman-Nordic system of months and weekdays - except, it seems, the mysterious place where MySQL evolves:
mysql> CREATE TABLE datetest (id INT, a_date DATE);
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO datetest VALUES(1, '2003-02-31');
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM datetest;
+------+------------+
| id | a_date |
+------+------------+
| 1 | 2003-02-31 |
+------+------------+
1 row in set (0.00 sec)
So, what's the day before February 31st?
mysql> SELECT DATE_SUB('2003-02-31', INTERVAL 1 DAY);
+----------------------------------------+
| DATE_SUB('2003-02-31', INTERVAL 1 DAY) |
+----------------------------------------+
| 2003-03-02 |
+----------------------------------------+
1 row in set (0.00 sec)
Which is of course two days before the day after February 31st:
mysql> SELECT DATE_ADD('2003-02-31', INTERVAL 1 DAY);
+----------------------------------------+
| DATE_ADD('2003-02-31', INTERVAL 1 DAY) |
+----------------------------------------+
| 2003-03-04 |
+----------------------------------------+
1 row in set (0.00 sec)
So what kind of checking does MySQL do on date values? A hint:
If you use really malformed dates, the result is NULL.
------------------------
Хей, внимавайте като работите с дати в MySQL ;)
но един познат ми се изсмя и взех да се замислям дали да не мина на нещо с повече перспектива (MySQL в случая).
<------
MySQL не е конкурент на Interbase/Firebird, тъй като и липсват
доста неща (хората преди мен ги казаха). Ползва се основно във Web-програмирането, с което май се изчерпва сферата и на действие.
тука:
[линк]
има описания на някои "сладки" (в големи кавички) неща, които ще
направят работата ви с MySQL да не е прекалено лека ;)
Ще цитирам само едно:
1.14 February 31st
Throughout history many different calendar systems have been developed around the world. Although the way of counting years still varies, most countries and regions have adopted the Roman-Nordic system of months and weekdays - except, it seems, the mysterious place where MySQL evolves:
mysql> CREATE TABLE datetest (id INT, a_date DATE);
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO datetest VALUES(1, '2003-02-31');
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM datetest;
+------+------------+
| id | a_date |
+------+------------+
| 1 | 2003-02-31 |
+------+------------+
1 row in set (0.00 sec)
So, what's the day before February 31st?
mysql> SELECT DATE_SUB('2003-02-31', INTERVAL 1 DAY);
+----------------------------------------+
| DATE_SUB('2003-02-31', INTERVAL 1 DAY) |
+----------------------------------------+
| 2003-03-02 |
+----------------------------------------+
1 row in set (0.00 sec)
Which is of course two days before the day after February 31st:
mysql> SELECT DATE_ADD('2003-02-31', INTERVAL 1 DAY);
+----------------------------------------+
| DATE_ADD('2003-02-31', INTERVAL 1 DAY) |
+----------------------------------------+
| 2003-03-04 |
+----------------------------------------+
1 row in set (0.00 sec)
So what kind of checking does MySQL do on date values? A hint:
If you use really malformed dates, the result is NULL.
------------------------
Хей, внимавайте като работите с дати в MySQL ;)
Re: Нещо не схващам ...
Супер си му го казал! Най-лесно е някой като не може да се справи с нещо да го оплюе! Че FireBird си има кусури - има си! Но хайде седни и пиши икономически софтуер (аз това правя) със всичката му смахната бизнес логика без Stored procedures, Views i т.н. (не че е невъзможно). В момента поддържам БД, с размер около 2 GB и милиони записи в нея и имам само 1 случай със счупена транзакция. В нея пишат едновременно 24 каси на 3 супермаркета и досега не съм имал проблеми.