| 1.1, Stanislaus (ok), 15:17, 14/02/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Странную альтернативу двигает автор... Не смотря на то, что в некоторых областях key/value databases действительно применимы, реляционную модель В БОЛЬШИНСТВЕ областей заменить сложно.
The responsibility of ensuring data integrity falls entirely to the application. API
Data is created, updated, deleted, and retrieved using API method calls.
Уже настораживает. А чем тогда мешает создать в postgreSQL одну таблицу и назвать ее доменом. Уже отсутствуют реляционные связи.
CREATE TYPE value_type AS (
maker text,
model texp,
price double presicion,
...
);
CREATE TABLE domain_one (
key bigserial,
value value_type
);
А теперь еще и кластеризуем с помощью plproxy.
Кроче, автор меня не убедил, что нужно отказываться от реляционных СУБД (подчеркиваю слово СУБД) в пользу реализации АПИ в приложении.
| | |
| |
| 2.3, geekkoo (ok), 19:45, 14/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
Угумс. Можно и так. Потом сравниваем скорости и убеждаемся, что постгрес проигрывет на порядки ...
| | |
| |
| 3.14, mnimd (ok), 22:37, 15/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Угумс. Можно и так. Потом сравниваем скорости и убеждаемся, что постгрес проигрывет на порядки ...
При всем уважении к Постгрес и к ее инструментарию, в логической реализации реляционной модели в Постгрес допущена одна очень грубая концептуальная ошибка, что фактически сводит на "нет" реляционную алгебру в Постгрес.
Конечно, для тех, кто смотрит на Постгрес исключительно с практической точки зрения, этот факт несущественен, однако им следует быть крайне осторожными, когда они заявляют, что пользуются именно реляционной системой в случае использования Постгрес.
| | |
| |
| |
| 5.31, mnimd (ok), 11:21, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Какая ошибка?
Ну вот, после всего сказанного (см. по номерам сообщений) наконец-то хоть кто-то задал этот вопрос.
| | |
| |
| 6.32, geekkoo (ok), 12:31, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>Какая ошибка?
>
>Ну вот, после всего сказанного (см. по номерам сообщений) наконец-то хоть кто-то
>задал этот вопрос.
Задал-то он его задал, а вот получит ли ответ? Судя по моему предыдущему опыту - вряд-ли ...
| | |
| |
| 7.34, mnimd (ok), 12:42, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Задал-то он его задал, а вот получит ли ответ? Судя по моему предыдущему опыту - вряд-ли ...
Вот именно вы, geekkoo, в отличии от некоторых, вполне способны найти этот ответ самостоятельно. Если он вас действительно интересует, конечно.
| | |
|
| 6.33, Arsenicum (?), 12:39, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>> Ну вот, после всего сказанного (см. по номерам сообщений) наконец-то хоть кто-то задал этот вопрос.
Ну вот, после всего сказанного вопрос остаётся в силе.
| | |
| |
| 7.35, mnimd (ok), 12:45, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Ну вот, после всего сказанного вопрос остаётся в силе.
А я и не спорю, что это важный вопрос. Вы только подтвердили, что вопрос остается в силе.
| | |
|
|
|
|
|
| 2.4, geekkoo (ok), 20:00, 14/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>>Уже настораживает.
Что именно? Есть куча баз данных, которые работают в режиме - одно приложение, одна база. Какой тогда смысл дублировать проверку на целостность внутри сервера, если ее можно выполнить (а можно и не выполнять) на стороне приложения. И RDBMS за собой тянут ещё кучу подобного оверхеда, включая парсер SQL.
Т.е. это хорошо заметно - решая более общий случай, получаешь потерю скорости в два раза. API и нужно для того, чтобы решение точно соответствовало задаче.
| | |
| |
| 3.5, vitek (??), 00:40, 15/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Что именно? Есть куча баз данных, которые работают в режиме - одно приложение, одна база. Какой тогда смысл дублировать проверку на целостность внутри сервера, если ее можно выполнить (а можно и не выполнять) на стороне приложения.
странное утверждение. особенно для много-пользовательской работы.
не говоря о том, что так называемая проверка на целостность обычно сопровождается индексами. или Вы какие-то другие приложения имели ввиду?
один пример - после перехода evolution на sqlite потребление ОЗУ сократилось в трое, а скорость работы увеличилась. да и вообще, использование встраиваемых sql приложениями заметно выросло.
>Т.е. это хорошо заметно - решая более общий случай, получаешь потерю скорости в два раза. API и нужно для того, чтобы решение точно соответствовало задаче.
ещё более хорошо заметно, что этот подход хорош только для проектов, которые ещё не доросли до требований, которые при их изначальном проектировании не планировались. тот же пример с evolution.
| | |
| |
| 4.6, geekkoo (ok), 13:41, 15/02/2009 [^] [^^] [^^^] [ответить] | +/– | Ну, про индексы пока речи не шло Вопрос пока только, что у нас есть одна таблиц... большой текст свёрнут, показать | | |
| |
| 5.18, User294 (ok), 01:41, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Только по условиям задачи - нужно ли нам
>полное отношение?
А вот будет база хоть немного посложнее и ситуация начнет напоминать программирование на асме - вроде в результате круто и быстро, но начиная с некоторого объема кода башню програмеру срывает и получается просто трудноподдерживаемое лоскутное одеяло в котором черт ногу сломит.
| | |
| |
| 6.19, mnimd (ok), 02:00, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>Только по условиям задачи - нужно ли нам полное отношение?
>
>А вот будет база хоть немного посложнее и ситуация начнет напоминать программирование на асме - вроде в результате круто и быстро, но начиная с некоторого объема кода башню програмеру срывает и получается просто трудноподдерживаемое лоскутное одеяло в котором черт ногу сломит.
Значит по-вашему то, что "башню програмеру срывает", и когда "получается просто трудноподдерживаемое лоскутное одеяло", по-вашему это зависит именно от выбора языка, а не от способностей "програмера". И по-вашему именно "асм" может "снести башню" сильнее, чем что-либо другое. И по вашему "лоскутные одеяла" появляются именно в результате использования непонятных для вас языков. И по-вашему языки с кажущейся легкостью понимания без знания основ и низким порогом входной квалификации, эти языки по-вашему не провоцируют чайников на штамповку эти самых "лоскутных одеял" в больших количествах.
Сразу видно, что разработками вы толком и не занимались.
И процитированную вами фразу вы скорее всего не поняли. А просто так, на удачу, в традиционной своей манере вставили комментарий.
| | |
| |
| 7.21, User294 (ok), 02:49, 16/02/2009 [^] [^^] [^^^] [ответить] | +/– | Это значит что вы не понимаете что есть некие очевидные соотношения, только и вс... большой текст свёрнут, показать | | |
| |
| 8.26, mnimd (ok), 10:11, 16/02/2009 [^] [^^] [^^^] [ответить] | +/– | Между любыми сущностями или явлениями всегда можно найти какое-то соотношение В... большой текст свёрнут, показать | | |
| |
| 9.39, User294 (ok), 08:10, 17/02/2009 [^] [^^] [^^^] [ответить] | +/– | Да, я их увидел И проверил на своей шкурке So what Потому что приведение всего ... большой текст свёрнут, показать | | |
| |
| 10.41, mnimd (ok), 19:11, 17/02/2009 [^] [^^] [^^^] [ответить] | +/– | Большую часть сообщения вы пытаетесь оправдаться якобы излишним вниманием к свое... большой текст свёрнут, показать | | |
| |
| 11.43, User294 (??), 21:12, 17/02/2009 [^] [^^] [^^^] [ответить] | +/– | Я не пытаюсь оправдаться вы о себе больно много мните, уважаемый мне на вас и в... большой текст свёрнут, показать | | |
| |
| |
| 13.45, mnimd (ok), 22:16, 17/02/2009 [^] [^^] [^^^] [ответить] | +/– | Наследование хорошо согласуется с реляционной моделью Как впрочем и объектная м... текст свёрнут, показать | | |
| 13.46, mnimd (ok), 00:29, 18/02/2009 [^] [^^] [^^^] [ответить] | +/– | Кстати о Третьем манифесте Вот вы сами, geekkoo, и практически нашли ответ на в... текст свёрнут, показать | | |
|
| 12.47, mnimd (ok), 18:00, 18/02/2009 [^] [^^] [^^^] [ответить] | +/– | Практически все ваше сообщение состоит из оправданий по поводу ваших предыдущих ... большой текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
| 3.12, User294 (ok), 21:52, 15/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>стороне приложения. И RDBMS за собой тянут ещё кучу подобного оверхеда,
>включая парсер SQL.
Ага, какой-нить sqlite весит ~300 кил (как статичный код).С парсером sql и движком базы.Что-то я его тяжелым монстром с диким оверхедом обозвать ну никак не могу.
| | |
| |
| 4.20, mnimd (ok), 02:21, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Вы как всегда продолжаете демонстрировать всю глубину ваших познаний в области программирования.
>>стороне приложения. И RDBMS за собой тянут ещё кучу подобного оверхеда, включая парсер SQL.
>
>Ага, какой-нить sqlite весит ~300 кил (как статичный код).С парсером sql и движком базы.Что-то я его тяжелым монстром с диким оверхедом обозвать ну никак не могу.
В том-то и дело, что он и является сам по себе эти самым оверхедом. А вы значит считаете его движком. Ну да, все конечно относительно. Какую-нибудь библиотеку для чтения-записи dbf-файла тоже можно считать движком. И чего там больше по-вашему - движка базы или парсера SQL с "оверхедом"? Учтите при этом полную блокировку всего файла БД при начале транзакции. И прочее количество функционала из области "движков БД".
И значит вы считаете, что для библиотеки 300k (статичного кода) - это очень мало по-вашему. Кстати, а что вы имели в виду, под статичным кодом?
| | |
| |
| 5.22, User294 (ok), 03:06, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>В том-то и дело, что он и является сам по себе эти
>самым оверхедом. А вы значит считаете его движком.
Гм.Просто у других в таком объеме кода чисто движок (страничная логика, транзакционные логи, b-деревья или что там у них заместо, ...) далеко не всегда умещаются в эти 300 кил.
>И чего там больше по-вашему - движка базы или парсера SQL
>с "оверхедом"?
В таком контексте затрудняюсь сравнить, не заморачивался.Зато знаю что допустим беркелеевская база от сонного кота, оперирующая (key, value) нифига не меньше весит.Хоть там и нет парсера SQL... =)
>Учтите при этом полную блокировку всего файла БД при
>начале транзакции. И прочее количество функционала из области "движков БД".
И что?Блокировки и в базах (key, value) бывают.Вон у того же сонного кота в базе блокировки есть.Равно как и транзакции.В результате не больно то оно мало весит.Хоть и без парсера SQL.По-моему оно даже тяжелее sqlite'а получается в итоге.Хотя казалось бы всего-то база оперирующая парами (key, value) :)
>И значит вы считаете, что для библиотеки 300k (статичного кода) - это
>очень мало по-вашему.
"А случаи бывают разными" (с) анекдот :).Если у меня однокристалка где памяти в сумме меньше - 300Кб за "очень мало" не считается.На обычном десктопе\сервере 300 Кб - достаточно незначительный размер кода.
>Кстати, а что вы имели в виду, под статичным кодом?
Вероятно вопрос в том что я имел в виду под размером статичного кода?Это размер на который распухает бинарь при статической линковке с некоей либой при юзании этой самой либы и ее функционала.Это (примерно) соответствует размеру кода этой либы.Достаточно распостраненная методика оценки увесистости чего-либо.Я думал это очевидно - вроде довольно популярный у програмеров "писькомер", странно что мимо вас прошло.
| | |
| |
| 6.24, geekkoo (ok), 09:03, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>
>>Учтите при этом полную блокировку всего файла БД при
>>начале транзакции. И прочее количество функционала из области "движков БД".
>
>И что?Блокировки и в базах (key, value) бывают.Вон у того же сонного
>кота в базе блокировки есть.Равно как и транзакции.В результате не больно
>то оно мало весит.Хоть и без парсера SQL.По-моему оно даже тяжелее
>sqlite'а получается в итоге.Хотя казалось бы всего-то база оперирующая парами (key,
>value) :)
>
Блокировки есть. По-страничные при записи. А конфликт между чтением-записью вообще можно обойти за счет мультиверсионности.
>[оверквотинг удален]
>десктопе\сервере 300 Кб - достаточно незначительный размер кода.
>
>>Кстати, а что вы имели в виду, под статичным кодом?
>
>Вероятно вопрос в том что я имел в виду под размером статичного
>кода?Это размер на который распухает бинарь при статической линковке с некоей
>либой при юзании этой самой либы и ее функционала.Это (примерно) соответствует
>размеру кода этой либы.Достаточно распостраненная методика оценки увесистости чего-либо.Я думал это
>очевидно - вроде довольно популярный у програмеров "писькомер", странно что мимо
>вас прошло.
| | |
| 6.29, mnimd (ok), 10:57, 16/02/2009 [^] [^^] [^^^] [ответить] | +/– | Ну вот вы сами и подтвердили мои слова, что он в отличии от других является скор... большой текст свёрнут, показать | | |
| |
| 7.40, User294 (ok), 09:10, 17/02/2009 [^] [^^] [^^^] [ответить] | +/– | Как всегда - благородный дон прочел то что хотел прочитать между строк он сам, а... большой текст свёрнут, показать | | |
| |
| 8.42, mnimd (ok), 20:42, 17/02/2009 [^] [^^] [^^^] [ответить] | +/– | По смыслу первой цитаты видно, что вы посчитали блокировку чем-то нежелательным ... большой текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.13, mnimd (ok), 22:29, 15/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Странную альтернативу двигает автор... Не смотря на то, что в некоторых областях key/value databases действительно применимы, реляционную модель В БОЛЬШИНСТВЕ областей заменить сложно.
Вы можете привести конкретно примеры случаев, в которых по-вашему реляционную модель сложно заменить. По крайней мере, действительно ли можно утверждать, что таких случаев большинство?
>Уже настораживает. А чем тогда мешает создать в postgreSQL одну таблицу и назвать ее доменом. Уже отсутствуют реляционные связи.
Очередной пример непонимания разницы между реляционной моделью и стандартом SQL. То что в SQL понятие "таблица" существует - это факт? А насколько уместно вообще применять термин "таблица" в реляционной модели? И насколько вообще стандарты SQL и их реализации соответствуют реляционной модели? И, наконец, что мешает реализовать реляционную модель с помощью механизма key-value?
P.S. Я ничего не имею против самой реляционной модели данных. Однако, насколько хорошо она реализована в существующих системах?
| | |
| |
| 3.16, Stanislaus (ok), 00:55, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>P.S. Я ничего не имею против самой реляционной модели данных. Однако, насколько
>хорошо она реализована в существующих системах?
Может реляционная модель в своем чистом виде немного не практична и не очень интересна?
Поэтому те, кто пытается адаптировать ее для практических целей, решают допускать "ошибки", ради практичности. В принципе, разработчики postgreSQL этого не скрывают и нам об этом сообщают. PostgreSQL is a powerful, open source object-relational database system.
> То что в SQL понятие "таблица" существует - это факт? А насколько уместно вообще применять термин "таблица" в реляционной модели?
"table"="relvar", "column"="attribute", "row"="tuple", как то привык, что они взаимозаменяемы. Мы же говорим о базах данных, а не моделях =).
>И, наконец, что мешает реализовать реляционную модель с помощью механизма key-value?
Ну, помешает терминология наверное. =)
| | |
| |
| 4.17, mnimd (ok), 01:38, 16/02/2009 [^] [^^] [^^^] [ответить] | +/– | Практична она или нет, зависит от конкретной реализации То что существует мало ... большой текст свёрнут, показать | | |
| |
| 5.25, geekkoo (ok), 09:08, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> То что в SQL понятие "таблица" существует - это факт?
>
>Я случайно поставил знак вопроса. Я хотел это сказать в утвердительной форме.
>
Читая предыдущий параграф, я уж было подумал, что у вас точка на клавиатуре отломилась, и вы её повсюду вопросом заменили ;)
| | |
| |
| 6.27, mnimd (ok), 10:16, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Читая предыдущий параграф, я уж было подумал, что у вас точка на клавиатуре отломилась, и вы её повсюду вопросом заменили ;)
И запятые у меня тоже последнее доживают.
| | |
|
|
|
|
|
| 1.2, User294 (ok), 16:32, 14/02/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Не, key\value это круто и (иногда) весьма даже рулит.Но, блин, только иногда.Утверждать что всегда надо юзать только такие БД - что-то типа утверждения что программы необходимо всегда писать только на асме :)
| | |
| |
| 2.7, s390 (?), 15:41, 15/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
 Ага. А ещё плоские файлы есть.;-)
С фиксированными полями - скорость просто бещенная. И никакого специализированного API учить не надо.
Если еще запихать туда списочную структуру в виде JSON или XML - уж гибкость то...
От прочтения статьи ощущение что автор сильно ушибленный, и с вопросами обработки данных имел дело на уровне написания телефонного справочника секретарши для фирмы "Рога и Копыта".
PS. Если вспомнить что ещё иерархические с сетевыми СУБД вполне так себе неплохо живут...
| | |
| |
| 3.8, Я (??), 16:27, 15/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
в питоне pickle с этим справляется и с json тоже.
| | |
| 3.9, geekkoo (ok), 18:19, 15/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Ага. А ещё плоские файлы есть.;-)
>С фиксированными полями - скорость просто бещенная. И никакого специализированного API учить
>не надо.
Зачем передергивать? Ага, давайте потом прицепим к файлу вторичную индексацию, приделаем транзакции, page-level locks, курсоры, распределенные операции. Делов то ...
>Если еще запихать туда списочную структуру в виде JSON или XML -
>уж гибкость то...
>
>От прочтения статьи ощущение что автор сильно ушибленный, и с вопросами обработки
>данных имел дело на уровне написания телефонного справочника секретарши для фирмы
>"Рога и Копыта".
>PS. Если вспомнить что ещё иерархические с сетевыми СУБД вполне так себе
>неплохо живут... | | |
| |
| 4.11, geekkoo (ok), 18:41, 15/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>Зачем передергивать? Ага, давайте потом прицепим к файлу вторичную индексацию, приделаем транзакции,
>page-level locks, курсоры, распределенные операции. Делов то ...
>>Если еще запихать туда списочную структуру в виде JSON или XML -
>>уж гибкость то...
>>
>>От прочтения статьи ощущение что автор сильно ушибленный, и с вопросами обработки
>>данных имел дело на уровне написания телефонного справочника секретарши для фирмы
>>"Рога и Копыта".
>>PS. Если вспомнить что ещё иерархические с сетевыми СУБД вполне так себе
>>неплохо живут...
Никто и не говорит, что нашли серебрянную пулю.
Я вот в какой-то книжке прочитал, что есть три user-case:
1) Статичные (более-менее) данные и динамические запросы. Условно говоря, у нас есть набор данных и мы не вполне знаем, что именно из этих данных мы хотим извлечь. Это SQL.
2) Статичные данные и статичные запросы. LDAP - самое оно для этого.
3) Динамичные данные и статичные запросы. Т.е. данные меняются очень быстро (генерируются автоматически), а запросы происходят редко и имеют фиксированную структуру. Это как раз ниша этих key-value баз данных.
| | |
|
|
| 2.15, mnimd (ok), 22:46, 15/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Не, key\value это круто и (иногда) весьма даже рулит.Но, блин, только иногда.Утверждать что всегда надо юзать только такие БД - что-то типа утверждения что программы необходимо всегда писать только на асме :)
Утверждать, что всегда следует использовать использовать "только такие БД", это конечно сугубо личное мнение авторов статьи.
Также как и утверждение, что что-то "рулит" только иногда - это тоже всего лишь чье-то личное мнение.
Все зависит от вкусов, знаний и умений. В чьих-то руках и "асм" будет всегда "рулить", а у кого-то даже на SQL будет что-то получаться только "иногда".
| | |
| |
| 3.23, User294 (ok), 03:15, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Все зависит от вкусов, знаний и умений. В чьих-то руках и "асм"
>будет всегда "рулить", а у кого-то даже на SQL будет что-то
>получаться только "иногда".
Видел несколько проектов на асме где объем кода более нескольких десятков кил.Хоть застрелите не понимаю что там рулит - выглядит такое довольно уныло.Поскольку в таком виде написаны обычно изделия проприетарной эпохи - пруфлинка не будет.Хотя в качестве примера могу сказать например про сорц старого авардовского биоса - типовой представитель такого кода ;).Глядя на оный невольно понимаешь почему более новые биосы типа coreboot'а пишут на сях.Такой объем функционала на асме сооружать получается попросту некомфортно.
| | |
| |
| 4.28, mnimd (ok), 10:21, 16/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Видел несколько проектов на асме где объем кода более нескольких десятков кил.Хоть застрелите не понимаю что там рулит - выглядит такое довольно уныло.Поскольку в таком виде написаны обычно изделия проприетарной эпохи - пруфлинка не будет.Хотя в качестве примера могу сказать например про сорц старого авардовского биоса - типовой представитель такого кода ;).Глядя на оный невольно понимаешь почему более новые биосы типа coreboot'а пишут на сях.Такой объем функционала на асме сооружать получается попросту некомфортно.
Значит заключение о том, что пары (key, value) по-вашему "рулят" только иногда, это заключение вы сделали на сновании того, что вам довелось увидеть какие-то проекты "на асме где объем кода более нескольких десятков кил".
| | |
|
|
|
| 1.48, Аноним (48), 08:37, 20/02/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Почитал всю эту вату, которую тут раскатали. Особенно заинтересовало заявление mnimd об концептуальной ошибке в постгресе. После прочитал все комменты. Кроме этого заявления больше ничего не нашёл. Где про это почитать-то можно? И желательно не между строк, а для чайников, черным по белому..
| | |
|
