1.1, gordev (ok), 10:56, 05/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
а почему не сравнивали с ораклом каким нибудь, или на худой конец с файербёрдом?
| |
1.2, Аноним (-), 12:30, 05/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Почему графика нет на котором сразу понятно что и как работает.
А читать эту хрень нет желания
| |
1.3, Veter (??), 15:14, 05/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> а почему не сравнивали с ораклом каким нибудь, или на худой конец с файербёрдом?
Сейчас интереснее неадминистрируемые СУБД, и те, которые можно легко перемещать между хостами. Опять же, нагрузка на самое узкое место - подсистему ввода-вывода для проектов на SQLite на порядки ниже. С одной стороны, есть ограничение, что кол-во модифицирующих транзакций в секунду ограничено примерно сотней, с другой стороны - максимальная нагрузка на жесткий диск заранее известна и перегрузки не будет. Если учесть, что при средней нагрузке в два десятка модифицирующих транзакций в секунду за год получается база в десятки гигабайт, то становится понятно - для большинства проектов этого достаточно (и нужен всего лишь один винт 10 000 rpm, так что зеркало через drbd можно держать на другой машине, и это надежнее получается, чем просто зеркальный рэйд).
В классе клиент-серверных СУБД вместо того, чтобы удвоить производительность, добавив второй идентичный хост, приходится использовать вдесятеро более дорогой сервер. Или, если проект допускает, несколько серверов с репликацией между ними, что опять же не дает линейного масштабирования, да еще и значительно усложняет администрирование.
| |
|
2.11, Одмин (?), 16:11, 07/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Извините, это какой-то поток сознание про "перегрузку жёстких дисков".
Есть куча нюансов использования sqlite. Оно не всегда и не везде быстрее и возможности очень скромны. В некоторых случаях целесообразнее вообще применять нереляционные БД.
| |
|
1.5, parad (ok), 20:28, 05/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
1) 'select ... from ... where ... in ( select ... )' - за такую конструкцию смело можно не читать статью.
2) если грамотно вдуплиться в реальность бытия - то станет ясно, что все подается в сравнении. к примеру - с другой бд, с другим администратором/архитектором бд и пр. из известных мне бд оракл чуть бы не единственный, который учитывает все возможные глубины некомпетентности разработчиков - и старается компенсировать это хардкодом, исправляющим типовые ошибки.
3) никогда бы не додумался, но один человек как-то ответил на вопрос причины категорического предпочтения постгресу - мускуль: при сотнях тысяч таблиц - мускуль работает быстрее. Этот пример можно записать как еще один камень в огород постгреса, или просто тупо погоревать над глупостями некторых. Я предпочел поржать...
4) п.3 - для сравнения.
5) не читал статью - только пробежался взглядом - если появится ответ - посмотрю - отвечу.
| |
|
2.6, tmc (?), 21:19, 05/12/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
Хм, а почему "за такую конструкцию смело можно не читать статью" В высшей степени часто употребляемая конструкция имеющая различные аспекты. ???
| |
2.7, DrNo (??), 22:23, 05/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Вы не любите кошек? Да вы просто не умеете их готовить!
PS Это про чушь по п.3. На заборе тоже написано..
| |
|
1.8, alexmest (ok), 02:49, 06/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Чего сравнивать, кому не нравится пусть покупают Oracle. DrNo правильно сказал, тут уж добавить нечего.
| |
1.9, phil (??), 03:34, 06/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
а там гораздо лучше с производительностью, судя по пресс-релизу. Его бы потестировали.
| |
1.10, trdm (ok), 13:44, 06/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Глупое сравнение с QSLite. Она же не сервер, а эмбедед.
Нужно сравнивать с сервера с сопоставимой архитектурой.
| |
|