1.1, max (??), 09:57, 15/04/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– |
Не знаю даже, хорошо это или плохо. С одной стороны все идет к вебизации и/или жаваскриптизации, но я как то привык что база данных должна делать лишь CRUD и не более, и делать она должна это хорошо, а все остальное дело рук программиста, как и в какой виде предоставлять данные из базы, а может старею, черт его знает... :-(
В целом хотел сказать, лично я не знаю даже как к этому отнестись...
| |
|
2.2, бедный буратино (ok), 10:10, 15/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Не знаю даже, хорошо это или плохо. С одной стороны все идет
> к вебизации и/или жаваскриптизации, но я как то привык что база
> данных должна делать лишь CRUD и не более, и делать она
> должна это хорошо, а все остальное дело рук программиста, как и
> в какой виде предоставлять данные из базы, а может старею, черт
> его знает... :-(
> В целом хотел сказать, лично я не знаю даже как к этому
> отнестись...
В json можно не только плоские данные выводить, как в обычной табличке, а с нормальной иерархией.
А ещё json нагляден. И валидный json в 99% случаев - валидный аналогичный python-овый dict. И наоборот.
json можно выразить текстом, понятным. Без этого данные от бд нужно сначала обрабатывать.
Ещё бы браузеры бы без костылей типа jsonp научились бы json обрабатывать - вот это было бы вообще хорошо.
И ещё. Для многих задач было бы достаточно бд + страница с js, без сервера (который в таких задачах занимается только преобразованием данных).
| |
2.3, hummermania (ok), 10:22, 15/04/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Плюс к хранению данных в JSON формате - снижение зависимости от схемы данных. Особенно когда необходимо хранить в базе документы, у которых время от времени меняется набор полей и иерархия. Очень актуально в условиях часто меняющегося законодательства. В реляционной БД частое изменение схемы данных ведет к усложению структуры таблиц. А при хранении документов в подобном формате приколы поджидают только в момент поиска. Но тут уже MapReduce в помощь. Одна кстати из причина массового появления NoSQL хранилищ - отвязка от схемы.
| |
|
3.4, бедный буратино (ok), 10:37, 15/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Плюс к хранению данных в JSON формате - снижение зависимости от схемы
> данных. Особенно когда необходимо хранить в базе документы, у которых время
> от времени меняется набор полей и иерархия. Очень актуально в условиях
> часто меняющегося законодательства. В реляционной БД частое изменение схемы данных ведет
> к усложению структуры таблиц. А при хранении документов в подобном формате
> приколы поджидают только в момент поиска. Но тут уже MapReduce в
> помощь. Одна кстати из причина массового появления NoSQL хранилищ - отвязка
> от схемы.
Это nosql базы и получаются, нет смысла из posgresql делать такую - таблички тоже нужны, а в вашем случае проще сразу nosql-базой воспользоваться.
Но при выборках из плоских табличек по интересным запросам имеет смысл делать вывод именно в json, как упорядоченной структуре данных, вместо того, чтобы надёргать 10 табличек и вручную поля расставлять.
Да и вообще - для json не нужен особый адаптер, можно хоть wget-ом опрашивать.
| |
|
4.5, hummermania (ok), 10:48, 15/04/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Пусть будет поддержка JSON в PostgreSQL. На случай когда много жирного легаси завязано под RDBMS и есть необходимость немного облегчить задачу хранения в нереляционном формате. Ну и насчет сразу юзать NoSQL - конечно я согласен. Более того, я больше на стороне NoSQL баз. И за совместное их применение в проектах. Давно уже пора перестать бояться поддерживать в проекте компоненты разной архитектуры, тем более если каждый применять для решения своей задачи.
| |
4.12, Аноним (-), 19:18, 15/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
> таблички тоже нужны, а в вашем случае проще сразу nosql-базой воспользоваться.
А как таблички связаны с NoSQL-ностью? :)
| |
|
|
4.7, hummermania (ok), 15:38, 15/04/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
CouchDB не? Представления да, но и хранения тож, с учетом некоторых особенностей конечно.
| |
|
5.8, бедный буратино (ok), 15:49, 15/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
> CouchDB не? Представления да, но и хранения тож, с учетом некоторых особенностей конечно.
Тогда давайте и dict() вспомним. :)
| |
|
4.10, Игрулькин (?), 15:54, 15/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
Глупый формализм. JSON - это строковый формат, позволяющий засунуть в него любые структурированные данные. Какая разница, кто, что и как "представляет"?
| |
|
5.13, ананим (?), 23:31, 15/04/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
индексы строить гораздо эффективней на «сырых» данных и куда эффективней.
про JSON — думаю лучше пусть будет, чем нет.
пользоваться этой функциональностью никто не обязывает.
| |
|
|
|
|
1.9, Игрулькин (?), 15:50, 15/04/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Крайне прогрессивное решение! У меня в куче баз хранятся именно JSON-данные, позволяющие в одно поле совать гетерогенную инфу (например, логи защиты, операций, системные события). Делать три таблицы под каждый тип - неудобно, а создавать безликое varchar просто с текстом события - бессмысленно. JSON тут бесподобен, а если ещё на нём можно делать выборку, вообще киллер-фича!
| |
|
2.16, AlexAT (ok), 07:33, 17/04/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
А если подумать, как это всё будет с индексами работать - то лучше нормально структурировать БД, а не изобретать жсоны.
| |
|
1.15, AlexAT (ok), 07:32, 17/04/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Пщщщщщ... Кто ответит: зачем велосипеду лестница?
Такое впечатление, что некоторые проекты скатываются в маразм...
Я всё понимаю - тренды там, розовые лошади. Но КАК это индексировать? Некоторые ведь там начнут хранить половину таблицы, вместо нормального структурирования. А потом будем удивляться - почему очередная поделка не использует индексы и ворочается по году на каждый чих.
| |
|
2.18, Аноним (18), 16:19, 28/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
Индексируются ведь значения. Строится функциональный индекс, если нужно что-то искать опираясь на значение из этого поля. А вот необходимость опираться выборке на неудобное - это на совести программиста.
| |
|
3.19, AlexAT (ok), 16:20, 28/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Индексируются ведь значения. Строится функциональный индекс, если нужно что-то искать
> опираясь на значение из этого поля. А вот необходимость опираться выборке
> на неудобное - это на совести программиста.
Об этой отсутствующей у ряда RADов совести и речь. Лучше вообще эту функциональность не добавлять, ибо скатит код в сраное говно.
| |
|
|
|