| 1.1, Guest (??), 12:54, 26/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Кто в курсе, не возьму в толк, почему всё так сконцентрировалось вокруг баз с функционалом ключ/значение? Для чего они?
До сих пор имел дело только с реляционными.
| | |
| |
| 2.2, arisu (ok), 12:55, 26/11/2013 [^] [^^] [^^^] [ответить]
| +17 +/– |
 > Для чего они?
для удобного хранения пар ключ/значение.
| | |
| |
| 3.36, qqqqq (?), 14:59, 27/11/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
 а пара "SQL запрос" -> "результат" чем не пара ключ-значение. Видишь ли это просто другая форма мышления.
| | |
| |
| 4.41, arisu (ok), 01:50, 28/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> а пара «SQL запрос» -> «результат» чем не пара ключ-значение.
тем, что в этом случае вклинивается как минимум один промежуточный слой — sql vm (и парзер, если это не precompiled statement). а на самом деле — больше слоёв. и всё только для того, чтобы в конце концов добраться до какого-нибудь b+ дерева. «nosql» (не люблю этот термин, ну да ладно) как раз промежуточные слои исключают.
всё вышесказаное, конечно, не означает «выкидываем sql, он не нужен!» каждому инструменту — своя ниша и своё применение.
| | |
| 4.43, badger (ok), 02:12, 28/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
 а пара "SQL запрос" -> "результат" тем не пара ключ-значение, что в общем случае одному ключу соответствует много значений
| | |
|
|
| 2.3, none_first (ok), 12:57, 26/11/2013 [^] [^^] [^^^] [ответить]
| –4 +/– |
 большинство бизнес процессов сложно/невозможно (без допущений и костылей) вписать в реляционную схему...
переменное число характеристик порождает доп. сущности в РСУБД
для отчетов, РСУБД - самое оно
| | |
| |
| 3.9, NikolayV81 (ok), 13:51, 26/11/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
 В ключ-значение "бизнес" процессы вообще с такими костылями ложатся, что почти никто не пытается, а вот во всяких личных страничках на сайтах ( большие соц. сети ), где за неверную ссылку голову никто не оторвёт, а время загрузки критично, можно хоть всю личную страницу пользователя в один отвязанный от окружающего мира объект запихивать, и загружать только его, а потом уже после отработки "показали клиенту его страничку" проверять валидность данных и их доступность по ссылкам.
| | |
| |
| 4.11, none_first (ok), 14:07, 26/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
одной из первых БД документооборота была Lotus Notes, кот. (вопщем) и является БД ключ/значение (при условии, что понятие "значение" несколько более расширено ;) )
и воркфло - прекрасно строится на этой платформе
попытка же ИБМ прикрутить DB2 (РСУБД) к домине, не увенчалась успехом и именно по причине костыльности реализации http://forum.codeby.net/topic22892.html?view=findpost&p=109606
т.е. реализовать-то можно - но это будет не реляционная схема;)
| | |
| |
| 5.12, NikolayV81 (ok), 14:57, 26/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> одной из первых БД документооборота была Lotus Notes, кот. (вопщем) и является
> БД ключ/значение (при условии, что понятие "значение" несколько более расширено ;)
> )
> и воркфло - прекрасно строится на этой платформе
> попытка же ИБМ прикрутить DB2 (РСУБД) к домине, не увенчалась успехом и
> именно по причине костыльности реализации http://forum.codeby.net/topic22892.html?view=findpost&p=109606
> т.е. реализовать-то можно - но это будет не реляционная схема;)
Логика была запихана в клиентский модуль. С зависимостями, актуальностью, достоверностью данных и атомарностью операций проблемы.
1C Тоже с dbf начинало и что?
По поводу ссылки, высосанная из пальца задача, данные которые не нужно обрабатывать, нет смысла хранить, если это результирующий отчёт, то его нужно формировать, и возможно фиксировать в те же blob поля (любой тип туда влазит, аналог не типизированного value).
| | |
| |
| 6.15, none_first (ok), 15:27, 26/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Логика была запихана в клиентский модуль. С зависимостями, актуальностью, достоверностью >данных и атомарностью операций проблемы.
>1C Тоже с dbf начинало и что?
и то - 1С не стала РСУБД (несмотря на использование "их" как подложки), у неё есть аппсервер, кот. и есть "костыль" к БД
атомарность в вокфло на каком уровне нужна и какими средствами, у сущ. в РСУБД, многозначные поля и разнотипные данные реализуются, в рамках одного документа?
и наборчик ёрпов:
САП - надстройка над РСУБД
Ахапта - тожсамое
...
"логика запихана в клиентский модуль";)
| | |
| |
| 7.16, NikolayV81 (ok), 15:55, 26/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>[оверквотинг удален]
> и то - 1С не стала РСУБД (несмотря на использование "их" как
> подложки), у неё есть аппсервер, кот. и есть "костыль" к БД
> атомарность в вокфло на каком уровне нужна и какими средствами, у сущ.
> в РСУБД, многозначные поля и разнотипные данные реализуются, в рамках одного
> документа?
> и наборчик ёрпов:
> САП - надстройка над РСУБД
> Ахапта - тожсамое
> ...
> "логика запихана в клиентский модуль";)
"многозначные поля и разнотипные данные реализуются" это какие данные? про те которые не нужны для обработки - реализация blob, если с первого раза не понятно. Если данные надо обрабатывать, искать, сортировать ( выбирать подборку документов по вложениям, характеристикам, то это вполне себе данные с конкретными типами ).
А так выберете из универсального key-value в котором контракты, все те которые в ценах на 13 июля имели добавленную стоимость более n-руб, в разрезе удалённых филиалов и которые были заключены менеджерами нанятыми начиная с 2009 года.
Трёхзвенная архитектура нужна по причине необходимости синхронизации между процессами, т.к. РСУБД не для этого, если это не нужно достаточно двухзвенки, а вот реализовывать в каждом приложении ( конкретной епр-ке ) механизмы дублирующие функционал БД ( всё те же транзакции, каскадные зависимости данных, типизированные справочники ) ещё то извращение.
| | |
|
|
|
|
| 3.19, Аноним (-), 17:51, 26/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> большинство бизнес процессов сложно/невозможно (без допущений и костылей) вписать в реляционную
> схему...
> переменное число характеристик порождает доп. сущности в РСУБД
> для отчетов, РСУБД - самое оно
Аффтар, ты в глаза видал такую книгу, как Ричард Баркер - "ER-modeling"?
У меня впечатление, что ты ни о бизнес-процессах, ни о реляционном моделировании ничего не слышал, ну, кроме названия, конечно.
| | |
| |
| 4.24, none_first (ok), 19:48, 26/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> большинство бизнес процессов сложно/невозможно (без допущений и костылей) вписать в реляционную
>> схему...
>> переменное число характеристик порождает доп. сущности в РСУБД
>> для отчетов, РСУБД - самое оно
> Аффтар, ты в глаза видал такую книгу, как Ричард Баркер - "ER-modeling"?
> У меня впечатление, что ты ни о бизнес-процессах, ни о реляционном моделировании
> ничего не слышал, ну, кроме названия, конечно.
а ты вживую видал документооборот (именно воркфло) в больших компаниях со сложной структурой, постоянно меняющейся?
я полагаю ты только и слышал о чем-то, но ничего реального не видел ;)
| | |
|
| 3.38, vitalif (ok), 19:51, 27/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Это кстати вот как раз какое-то стильно-модно-молодёжное предубеждение, скажу я вам)
Если свалить все поля ваших классов кучей в редис - там вообще чёрт ногу сломит...
| | |
| |
| 4.42, arisu (ok), 01:52, 28/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
есть ещё и такой секрет же (прямо тут о нём и писали, кажется): для key/value можно «сесть и кодить», не надо заморачиваться разработкой схемы хранения данных и взаимосвязей. ну и что, что оно потом так аукнется, что мало не покажется? это потом будет, а код рубить уже сейчас можно!
| | |
|
|
| 2.5, Аноним (-), 13:17, 26/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
потому что хипсторы не осиливают теорию множеств и транзакции
| | |
| 2.6, Аноним (-), 13:31, 26/11/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
Хыхы. Все написавшие выше не правы!
Ключ значение работает тупо на несколько порядков быстрее и хорошо маштабируется. Что сейчас очень востребовано.
Если бы реляционнки работали на уровне мемкеша, то ничего бы больше нужно бы небыло.
| | |
| |
| 3.10, arisu (ok), 13:55, 26/11/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Ключ значение работает тупо на несколько порядков быстрее
…чего? ну вперёд, велосипедь сложные структуры данных со связями. посмотрю, за сколько ты навелосипедишь rdbms поверх key/value, и насколько оно в итоге будет тормозить.
| | |
| |
| 4.25, edwin (??), 19:54, 26/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
 >> Ключ значение работает тупо на несколько порядков быстрее
> …чего? ну вперёд, велосипедь сложные структуры данных со связями. посмотрю, за сколько
> ты навелосипедишь rdbms поверх key/value, и насколько оно в итоге будет
> тормозить.
Это не задача key store хранилищ.
Что касается обозначенной Вами задачи .... РСУБД хороший инструмент с наработанными шаблонами. Но не единственный - если выйти за рамки реляционной модели - много вкусных плюшек ждут Вас. К примеру работа со сложными структурами ....
Подобного рода задачи решаются другими инструментами - таким классом решений как документ ориентированные БД. К примеру - MongoDB. Там есть на что посмотреть ...
| | |
|
| 3.28, metallica (ok), 23:17, 26/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > Хыхы. Все написавшие выше не правы!
> Ключ значение работает тупо на несколько порядков быстрее и хорошо маштабируется. Что
> сейчас очень востребовано.
> Если бы реляционнки работали на уровне мемкеша, то ничего бы больше нужно
> бы небыло.
Эти ключ/значение базы для кеширования в памяти запросов к RDBMS backend обработчиками.
Чтоб не делать повторных запросов к sql базам.Если для какого-то представления
какой-то системы имеется модель данных в sql базе, и с разных клиентов поступают
запросы на получение этого представления, то бекенды его формируют, извлекая один и тот же
набор данных, относящиеся к соответствующей модели.Результат запроса к RDBMS сохраняется в
redis/memcached под каким-то ключом, а backend обработчик сначала проверяет
наличие данных той или иной модели в redis/memcached и только при их отстутствии лезет
в RDBMS. list=cache.get('MODEL_XXX','No')
if list=='No':
list = Model_XXX.objects.all()
| | |
| |
| 4.30, Аноним (-), 08:48, 27/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
КЭП? Интерактивные данные в кешить не вариант, тригерами будете их обновлять. Ваш вариан годится когда чтение сильно превышает запись и когда не важно время реального обновления данных у клиента.
| | |
| |
| 5.32, NikolayV81 (ok), 10:03, 27/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
> КЭП? Интерактивные данные в кешить не вариант, тригерами будете их обновлять. Ваш
> вариан годится когда чтение сильно превышает запись и когда не важно
> время реального обновления данных у клиента.
Может имелось в виду типа App сервера что-то, если мы точно знаем что и где мы обновляем, ничто не мешает нам организовать кэш, правда такой же кэш может быть организован и в БД, так что геморрой с реализацией может перекрыть выигрыш во времени отклика.
| | |
| |
| 6.35, metallica (ok), 11:11, 27/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Может имелось в виду типа App сервера
Стандартное MVC с ORM на java/python/ruby
> что и где мы обновляем
Каждая модель имеет уникальный символьный идентификактор и в СУБД и в кеше.
> правда такой же кэш может быть организован и в БД,
Есть возможности в фреймворках делать кеши в БД, но сохранение и извлечение
данных организовано тоже по принципу ключ/значение.
> что геморрой с реализацией
Дополнительные н несколько строчек кода.
| | |
|
| 5.34, metallica (ok), 11:03, 27/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
>когда чтение сильно превышает запись
Именно, когда читают куча клиентов, а пишут один два специализированных бекенда наполнителя
контента.
| | |
| |
| 6.37, Аноним (-), 16:59, 27/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
Хорошо, намажу толще.
В современном мире интерактива подход беспонтовый.
| | |
|
|
|
|
| 2.8, Клыкастый (ok), 13:45, 26/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 а я вот часто имею дело с данными, которым на роду написано ключ/значение. И очень печально, когда разработчики запихивают это в sql.
| | |
| |
| 3.20, Аноним (-), 18:15, 26/11/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
Конкретные примеры, что у Вас отлично ложится в "ключ-значение"
| | |
| |
| 4.22, edwin (??), 19:34, 26/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Конкретные примеры, что у Вас отлично ложится в "ключ-значение"
Добрый день.
Зачем Вы так категоричны ? Вы ведь никогда не ездите в Камазе в магазин ?
Примеров - вагон. Для иллюстрации - хранение данных http сессий в key store хранилище.
РСУБД тут никаким боком не упала - не ее это уровень.
| | |
| 4.33, Клыкастый (ok), 10:55, 27/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Конкретные примеры, что у Вас отлично ложится в "ключ-значение"
SIP сессии например
| | |
|
|
| 2.26, Аноним (-), 19:56, 26/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> почему всё так сконцентрировалось вокруг баз с функционалом ключ/значение?
Потому что
1) Быстрые.
2) Большинство реализаций не боится Бобби Тэйблса.
| | |
|
| 1.14, Аноним (-), 15:09, 26/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Опять споры уровня, что лучше: рубить лес лопатой или копать ямы топором.
| | |
| |
| 2.27, Аноним (-), 19:58, 26/11/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Опять споры уровня, что лучше: рубить лес лопатой или копать ямы топором.
Это опеннет, детка. Здесь любят летать на боинге в магазин и пытаться лететь на самокате через океан.
| | |
|
| 1.21, edwin (??), 19:24, 26/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Sentinel - ИМХО один из ключевых моментов этой версии ... как по мне - стало стабильнее.
| | |
|
