|
2.19, angra (ok), 18:41, 07/01/2016 [^] [^^] [^^^] [ответить] [↓] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +/– |
Задай этот вопрос гениям, работавшим над KDE PIM, которым не хватило sqlite для адресной книги, понадобился полноценный мускул.
Плееру, который просто проигрывает один файл, БД конечно без надобности, но среди плееров ведь есть не только mpg123 или mplayer, но и монстры типа amarok или itunes, у которых собственно проигрывание лишь малая часть функционала, а media library отлично ложится на реляционную модель БД.
Ну и наконец кроме плееров существует очень много разного софта, в том числе нуждающегося в SQL, транзакциях и триггерах(кстати, в sqlite они есть), но при этом не требующего высокой concurency, то бишь не нуждающегося в отдельном сервере БД.
| |
|
|
4.27, QuAzI (ok), 20:56, 07/01/2016 [^] [^^] [^^^] [ответить] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +1 +/– |
Не скажу, что XML не нужен вообще, но вы сейчас явно неудачный пример притянули за уши. И когда для народа проблема сделать пару таблиц (песни и их атрибуты, связь один ко многим в простейшем случае, по которым, кстати, удобно и быстро делается поиск на SQL), то появляются велосипеДИЩИ, которые используют XML во все щели где не надо. Я уже молчу про то, что XML - решето by design.
Опять же скорость и занимаемые объёмы.
Как вы, залечите XML-файл на 10000 записей, если он был повреждён, например, из-за отключения света в момент записи?
Ну и посмотрите на ту же мозиллу хотя бы. Ну не такие ж лохи, как я, там работают, но тем не менее sqlite там активно пользуется.
| |
|
|
|
7.40, ЧепуКто (ok), 06:52, 08/01/2016 [^] [^^] [^^^] [ответить] [↓] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +/– |
Чувак, вот все ты правильно говоришь... И про тормозной xml, и про реляционные связи (не зря оно называется реляционная СУБД), и, самое главное, про сферы применения... Одно зря - "ODF? Ну фиг его знает. Оно до сих пор так клёво поддерживается, что у меня все документы или в odt или в doc, а они бинарные. И либра выбирает по умолчанию odt, не odf. Про OOXML та же фигня. Почему?" Вот прям все впечатление испортил.
ODF - стандарт "файл открытого документа", который говорит, что документ должен состоять из некоторой файловой иерархии, где лежат XMLки, запакованный zip-ом.
ODT - ПОДВИД ODF, описание текстового документа как разновидности ODF. То же с ODS - табличный ODF.
Т.е.:
1. ODF <- ODT (ты, как сторонних реляционной теории, должен понять)
2. ODT НЕ бинарный.
Ввиду обобщенности ODF либра и не может выбрать его по умолчанию. В общем виде ODF - абстрактен и является шаблоном для ODT, ODS и остальных видов документов.
И, собственно, для хранения документов XML-форматы не так уж плохи. Сама идея (не скажу за упоротую реализацию что в ODF, что в OoXML) таки неплоха. Подумай о необходимости парсинга и генерации этих данных. Таки XML-ку руками без специфических драйверов собрать/разобрать проще. Впрочем, признаю, про сферы применения ты писал, и вопрос, скорее, именно в применимости.
| |
|
|
|
|
|
|
|
2.36, QuAzI (ok), 00:53, 08/01/2016 [^] [^^] [^^^] [ответить] [↓] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +2 +/– |
Легко ложится в БД, да, придётся делать аж не одну таблицу, от чего у кого-то видимо дико бомбит.
Легко ложится в JSON почти как есть, который поддерживается SQLite, после чего работать с ним становится легко и комфортно.
Так какую креативность оно развивает? Я вижу, с такими наклонностями (в экземплах), вы привлекаете много внимания дядек в белых халатах, не бойтесь их, будет просто "чик" как комарик и вас перестанет беспокоить злой и страшный SQLite
| |
|
|
4.52, QuAzI (ok), 11:00, 08/01/2016 [^] [^^] [^^^] [ответить] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +/– |
JSON появился почти в одно время с XML и отпочковался от JavaScript, он более лаконичный, легко читается, у него нет явных дыр типа этой http://habrahabr.ru/post/170333/ , скорость сериализации выше, его легче расширять.
Если там мало записей, то конечный пользователь не увидит разницы по перфомансу/ресурсам.
А вот если сущность не одна, а 1000000, то это совсем не оверхед. Тем более, если мне надо обрабатывать не все из них, а только какие-то конкретные. А вот держать в этой ситуации все 1000000 в памяти, чтобы вручную перелопатить их ища нужные - вот это знатный оверхед.
| |
|
|
|
|