
Dmitry
03.06.2017
14:17:42

Dmitriy
03.06.2017
14:17:43
я ниразу не dba, по этому смотрю с колокольни другой

Dmitry
03.06.2017
14:18:05

Dmitriy
03.06.2017
14:18:24
у меня есть парочка коллег, которые плотно на оракле сидят, говорят, что круто, но контора сама по себе очень гадкая

Google

Dmitry
03.06.2017
14:18:41

Muzaffar
03.06.2017
14:18:43

Dmitriy
03.06.2017
14:18:43
ну у меня большой опыт работы с pg и mysql, с ними мне нравится работать

Muzaffar
03.06.2017
14:19:23
ясно

Dmitry
03.06.2017
14:19:34
8 лет проработав с PLSQL сложилось четкое впечатление о том, что до оракла остальным еще расти и расти

Muzaffar
03.06.2017
14:19:51
к примеру я работаю с джава там очень удобно все это

Dmitriy
03.06.2017
14:19:54
plsql это native)
у pg тоже аналог есть, очень крутой

Dmitry
03.06.2017
14:20:35
если интересно - оракл насколько знаю единственный реализовал обычное и поколоночное хранение данных в кеше, причем настраивается когда так отдавать, а когда так. т.е. вот вам sql и nosql в одном флаконе

Muzaffar
03.06.2017
14:20:44
кстати на плскл сделан апекс

Dmitriy
03.06.2017
14:21:07
апекс тоже щупал, пока не настроил полноценный коннект
норм тема

Google

Muzaffar
03.06.2017
14:21:47

Dmitriy
03.06.2017
14:22:09
пока oci8 не сделал, работал с базой через apex

Dmitry
03.06.2017
14:22:47
контора гадкая в том плане, что если был отказ от техподдержки платной и покупалась лицензия на 1 проц, а спустя пару лет вы воткнули второй проц и решили расширить лицензию, то попросят оплатить эти пару лет техподдержки. ну да. они такие

Muzaffar
03.06.2017
14:23:09
хм ну ладно с ними :) никаких идей по моему вопросу? ну кроме носкула?

Dmitry
03.06.2017
14:24:40

Muzaffar
03.06.2017
14:25:10
так я про структуры базы спрашивал

Dmitry
03.06.2017
14:26:48
нет, не постгри. mysql 5.7 может хранить данные в json. вот это как раз наверное то что вам и нужно

Dmitriy
03.06.2017
14:27:10
искать в этом json как?
like?
или там реализован нормальный полнотекствый поиск?
в nosql все в json по дефолту
и всякие там сложные find методы работаеют очень шустро
она точилась для этих целей
есть антипаттерн "Золотой молоточек"
вот пихать в реляционку такие данные, считая мускул панацеей есть зло

Dmitry
03.06.2017
14:29:19
а если структуру придется менять и возможностей nosql не хватит?
в будущем

Dmitriy
03.06.2017
14:30:06
nosql этим и хорош, что ему не нужны данные структурированные

Dmitry
03.06.2017
14:30:34
согласен. а если заказчик попросит "доработать напильником" ? пути назад уже не будет

Google

Dmitriy
03.06.2017
14:30:39
каждом документе могут храниться данные независимо от соседних

Dmitry
03.06.2017
14:31:48
на данный пример согласен - nosql самое оно. но в перспективе...

Muzaffar
03.06.2017
14:33:25
или подходить надо из ООП?
там как бы если наследования то в базе мы получим не нормальную форму

Dmitriy
03.06.2017
14:36:02
В перспективе я проблем тоже не вижу. Если даже структура данных поменяется, mongo их сожрет и не пукнет даже.
в posgres да, работает с json отлично
даже есть индексы к ним
и отлично реализованный полнотекстовый поиск

Muzaffar
03.06.2017
14:36:57
получается мускул отстой?
?

Dmitry
03.06.2017
14:37:10
есть прагматики а есть новаторы просто

Dmitriy
03.06.2017
14:37:27

Dmitry
03.06.2017
14:37:39
все новое - не значит хорошее. монга давно появилась?

Dmitriy
03.06.2017
14:37:48
достаточно

Muzaffar
03.06.2017
14:38:01

Dmitriy
03.06.2017
14:38:23
когда нужны фичи, которых в стандарте sql не описано

Dmitry
03.06.2017
14:38:33
мускул не отстой. его просто готовить надо правильно. и сколько поваров - столько рецептов

Dmitriy
03.06.2017
14:38:50
запросы в мускуле сильно проще и не так требователен к соблюдению стандартов sql, как PG

Muzaffar
03.06.2017
14:38:54

Google

Dmitriy
03.06.2017
14:39:13
из коробки есть например uint поля
несколько движков для хранения данных
events
ну в каждой субд есть и плюсы и минусы

Muzaffar
03.06.2017
14:39:50
мы опять таки отходим от основного вопроса :)

Dmitriy
03.06.2017
14:40:04
nosql
либо pg+json
я все же за nosql

Dmitry
03.06.2017
14:40:35
в PLSQL можно все. а вот в мускуле логику в базе хранить не рекомендуется. а для полнотекстового поиска на мускуль вроде сфинкс прикручивается. у оракла искаропки есть полнотекстовый поиск

Dmitriy
03.06.2017
14:41:01
сфинкс крутая тема

Dmitry
03.06.2017
14:41:04
и да, у оракла есть продукт Oracle NoSQL ))

Dmitriy
03.06.2017
14:41:14
это платно все)

Dmitry
03.06.2017
14:41:18
сырой, но есть

Muzaffar
03.06.2017
14:41:35
Дмитрий Григорьев а Вы что скажете по моему вопросу?

Dmitry
03.06.2017
14:44:55
1. оракл. плюсы - функционалу завидуют все, всю логику можно запихнуть в базу. минусы - стоимость.
2. мускл+сфинкс (если надо полнотекстовый поиск). плюсы - стоимость, минусы - структуру тяжеловато будет описать, но возможно
3. monga и аналоги. плюсы - структура прямо то что надо. минусы - развитие проекта когда может потребоваться вытаскивать данные не select * from, а лихими джойнами с вложенными подзапросами и т.д. лечится вынесением всей логики в приложение.

Muzaffar
03.06.2017
14:46:10
так вы тоже предлагаете выбирать другую бд?

Dmitriy
03.06.2017
14:46:13
я присоеденюсь
nosql подойдет точно. Логику все в приложении нужно будет хранить

Dmitry
03.06.2017
14:48:19
я предлагаю оракл просто потому что хорошо его знаю (8 лет 24х7 распределенные бд). сейчас я работаю 2 года с мускулом - чувствую себя как в домашних тапочках, но иногда они оказываются дырявыми. nosql - круто, на нем работает БАК и госуслуги, но здесь нужно писать приложение. а для sql приложение нужно не писать, а "нарисовать"
https://habrahabr.ru/post/152477/

Google

Dmitriy
03.06.2017
14:49:56
Читал эту статью, неплохо написана

Dmitry
03.06.2017
14:50:59
да, если объем данных не более 10гб и расти почти не будет - есть бесплатная OracleXE. из ограничений - 10гб данных, 1 проц (лечится виртуалкой) и 1гб оперативки вроде бы (не лечится)
10гб можно вылечить линковкой на соседнюю базу, но это костыль
да, и оракл оперативку оооочень любит

Muzaffar
03.06.2017
14:57:29
знаю

Dmitry
03.06.2017
15:08:29
Да, самое главное то забыл спросить. Какие уровни изолированности транзакций поддерживает нескл база? Та же монга ?
чтение если мне не изменяет память там грязненькое )
поэтому эту часть работы нужно будет выносить в приложение
если у вас в расоряжении 5 бдшников и один разработчик - лучше sql, если у вас 5 разработчиков и нет бдшников - монга

Muzaffar
03.06.2017
15:25:37
я сам и бдщник и разработчик
)))
и дизайнер
)
как бы вот наброски но не учитывался ещё разновидность конструкций

Dmitry
03.06.2017
15:32:20
mysql?

Muzaffar
03.06.2017
15:32:39
да

Dmitry
03.06.2017
15:36:39
5.7 ? Inno?

Muzaffar
03.06.2017
15:37:08
да

Fike
03.06.2017
20:35:35