@mysql_ru

Страница 23 из 142
Dmitry
03.06.2017
14:17:42
даже php что бы затставить работать с ней нужно потанцевать, поставив oci8
если к напильнику в комплекте очки не доложили. это не значит что напильник плохой

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

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

Google
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 проц, а спустя пару лет вы воткнули второй проц и решили расширить лицензию, то попросят оплатить эти пару лет техподдержки. ну да. они такие

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

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

Страница 23 из 142