Правила     Закладки     Карма    Календарь    Журналы    Помощь    Поиск    PDA    Чат   
        СМС-ки
   
Пейджер выключен!
Страницы: (3) 1 2 [3]  ( Перейти к первому непрочитанному сообщению )  
Фильтр авторов:    показать 
  скрыть
  Ответ в темуСоздание новой темыСоздание опроса

> Флуд из темы о вакансии на Java-Junior , Перенес в отдельную ветку.
Ron  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 1043
Пользователь №: 41686
На форуме: 1 год, 3 месяца, 26 дней
Карма: 13




Цитата (Santehnick @ 17.10.2016 - 20:23)
И всё, теперь рсубд скорее проблема, чем решение без преимуществ над nosql решениями.

Никак нельзя так сказать. Это разные СуБД для решения разных задач. Будет это web или не web - совершенно никакой роли не играет.

Если у меня данные имеют огромную реляционную ценность (социальная сеть, самый яркий пример), то разумеется буду использовать реляционную СуБД. А если мне нужно хранить амбулаторные карты пациентов, то выберу Mongo.


--------------------
Жду 5.11.2017
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
brevis  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 264
Пользователь №: 39616
На форуме: 2 года, 6 месяцев, 21 день
Карма: 31




Цитата (Ron @ 17.10.2016 - 20:16)
Если у меня данные имеют огромную реляционную ценность (социальная сеть, самый яркий пример), то разумеется я буду использовать реляционную СуБД. А если мне нужно хранить амбулаторные карты пациентов, то выберу Mongo.

В Facebook, кстати, MySQL используют. Но используют они его как "хранилище пар ключ-значение, никаких join'ов".


--------------------
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Ron  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 1043
Пользователь №: 41686
На форуме: 1 год, 3 месяца, 26 дней
Карма: 13




Цитата (brevis @ 17.10.2016 - 22:06)
В Facebook, кстати, MySQL используют. Но используют они его как "хранилище пар ключ-значение, никаких join'ов".

Но это же ссылка не на официальный источник. =)



--------------------
Жду 5.11.2017
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Santehnick  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Абориген
*****

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 231
Пользователь №: 26735
На форуме: 5 лет, 8 месяцев, 27 дней
Карма: 15




Facebook использует mysql по историческим причинам. Они делали noSQL базу данных Cassandra чтобы выпилить наконец mysql, но что-то там не сложилось и от кассандры отказались. Google использует bigTable в своих проектах. Amazon использует DynamoDB. Все кто могут переезжают с реляционных баз на noSQL решения.

Цитата
Если у меня данные имеют огромную реляционную ценность (социальная сеть, самый яркий пример), то разумеется буду использовать реляционную СуБД.

Джойны в реляционной базе не работают при шардинге. Соответственно никакой реляционной ценности не будет. Будут только проблемы с шардингом и больше ничего.

NoSQL движение как раз и появилось, чтобы решать проблемы масштабируемости.
Поскольку реляционная модель появившаяся более 30 лет назад задолго до веба не может эффективно решать эти проблемы, этих проблем тогда не существовало. NoSQL это не для решения каких-то специфичных задач, это для решения любых задач, особенно в вебе.
PM
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Ron  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 1043
Пользователь №: 41686
На форуме: 1 год, 3 месяца, 26 дней
Карма: 13




Santehnick, ну хочешь делай всё на Монге. Я не считаю что это правильно, скорее наоборот, в большинстве случаев это НЕ правильно. Схему все-равно где-то надо хранить. Джойны все-равно надо как-то делать, и причем через задний проход. Вопрос: зачем использовать инструмент который для этого не подходит? Особенно всюду, где нужно и не нужно. Это с моей точки зрения крайне неразумно.

Я не отрицаю полезности Монги в определенных случаях. Это хорошая СуБД, интересная, под свои задачи даже незаменимая. Когда у нас открытые сущности (требуется schemaless) или огромный объем, особенно данных без связей. Документов. Она и называется Документарная СуБД, что нам как бы намкает на ее предназначение.

Но самое главное далеко-далеко-далеко не каждый проект потребует масштабируемости СуБД, даже сравнительно крупный.



--------------------
Жду 5.11.2017
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
jetistyum  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Эксперт
Группа переписки
Сообщений: 2605
Пользователь №: 5568
На форуме: 8 лет, 4 месяца, 26 дней
Карма: 30




Цитата (jetistyum @ 17.10.2016 - 11:17)
Отличная бд для веба, лучше чем реляционные. Веб должен обслуживать любые объемы траффика и решения соответственно должны быть распределенные.

Вот какое-то очень спорное утверждение. Пробовали сделать проект на чистой монге, очень зае*ались. Реляционная структура нужна для хранения данных, без нее либо "искусственные" реляции уровня приложения, или денормализация и оверхед при хранении данных. Эта бд не совсем для этих целей.
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Santehnick  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Абориген
*****

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 231
Пользователь №: 26735
На форуме: 5 лет, 8 месяцев, 27 дней
Карма: 15




Варианты со схемой:

1. В DDD есть доменные объекты, у них есть свойства и поведение. Свойства отображают текущее состояние доменного объекта, а поведение позволяет его изменить. Доменный объект сохраняется в базу. В базу попадают только свойства, которые есть в доменном объекте. Ничего лишнего не может попасть.

2. Можно использовать ODM (тоже самое что и ORM) и делать схемы.

3. Можно использовать валидацию в монго позволяющую делать почти всё тоже самое, что и схемы в рсубд и даже больше.

Варианты с джойнами

1. Не использовать джойны, вместо них использовать несколько запросов, как делают например некоторые ORM в php. И это более правильный подход.

2. Использовать left join в монго. Но это не работает при шардинге, так же как и в рсубд. Поэтому я бы использовал 1 вариант, он наиболее верный.
PM
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Santehnick  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Абориген
*****

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 231
Пользователь №: 26735
На форуме: 5 лет, 8 месяцев, 27 дней
Карма: 15




Цитата (jetistyum @ 18.10.2016 - 06:13)
Цитата (jetistyum @ 17.10.2016 - 11:17)
Отличная бд для веба, лучше чем реляционные. Веб должен обслуживать любые объемы траффика и решения соответственно должны быть распределенные.

Вот какое-то очень спорное утверждение. Пробовали сделать проект на чистой монге, очень зае*ались. Реляционная структура нужна для хранения данных, без нее либо "искусственные" реляции уровня приложения, или денормализация и оверхед при хранении данных. Эта бд не совсем для этих целей.

Да, джойны на уровне приложения. И это правильно. Джойны на уровне базы это всё перестает работать более чем на 1 сервере. Реляционная субд подойдет в закрытой корпоративной среде, где точно знаешь, что 1 сервер и реплики в крайнем случае со всем справится. Но для приложений, которые смотрят в мир, это плохое решение. Денормализация в некоторых случаях оправдана.

Просто многие приходят в монгу и пытаются использовать её таким же образом, каким они использовали рсубд, потом расстраиваются и говорят что у них ничего не получилось sad.gif
PM
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
jetistyum  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Эксперт
Группа переписки
Сообщений: 2605
Пользователь №: 5568
На форуме: 8 лет, 4 месяца, 26 дней
Карма: 30




Цитата (jetistyum @ 18.10.2016 - 09:13)
1. Не использовать джойны, вместо них использовать несколько запросов, как делают например некоторые ORM в php. И это более правильный подход.


Вот так и делали, но в таком случае растет число запросов растет экспоненциально например при построении грида данных по объектам, чьи свойства хранятся в "реляциях".



Цитата (Santehnick @ 18.10.2016 - 09:30)
Просто многие приходят в монгу и пытаются использовать её таким же образом, каким они использовали рсубд, потом расстраиваются и говорят что у них ничего не получилось


Этого требует архитектура приложения. Иначе, как я написал - оверхед при хранении и гемор при обновлении денорм. данных
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Santehnick  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Абориген
*****

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 231
Пользователь №: 26735
На форуме: 5 лет, 8 месяцев, 27 дней
Карма: 15




Цитата (jetistyum @ 18.10.2016 - 06:34)
Цитата (jetistyum @ 18.10.2016 - 09:13)
1. Не использовать джойны, вместо них использовать несколько запросов, как делают например некоторые ORM в php. И это более правильный подход.


Вот так и делали, но в таком случае растет число запросов растет экспоненциально например при построении грида данных по объектам, чьи свойства хранятся в "реляциях".

Просто нужно использовать жадную загрузку. Тогда чтобы выбрать например всех покупателей и все покупки этих покупателей, потребуется всего 2 запроса. Просто нужно немного подумать. База данных не виновата, что программист не включает мозг.

Цитата
Этого требует архитектура приложения. Иначе, как я написал - оверхед при хранении и гемор при обновлении денорм. данных

Вот странно да, раньше значит архитектура большинства приложений этого не требовала. Но стоило появиться mongo, как откуда то выросло невероятное количество каких-то странных приложений у которых внезапно появилась какая-то никому ранее неизвестная архитектура, которая вдруг стала требовать mongo. Причем такое количество, что mongo уже обогнала по популярности postgreSQL. Но на самом деле никаких специфичных архитектур нет. Это всё те же приложения, те же задачи, что были и ранее, но их делали на рсубд просто из-за отсутствия альтернатив.

Вот наверное в Google идиоты работают. Делают Google+, Youtube и еще кучу своих проектов на noSQL, а не на реляционных базах. Ага, ведь Google+ и Youtube это же совсем какая-то другая никому неизвестная архитектура, не такая как у большинства других веб проектов. Youtube видимо амбулаторные карты пациентов хранит.
PM
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
sergeiss  
Дата
Цитировать сообщение

Пользователь сейчас на форуме



Сидел он, дум великих полон - и вдаль глядел
******

Профиль
Группа: Эксперт
Группа переписки
Сообщений: 14969
Пользователь №: 4190
На форуме: 8 лет, 9 месяцев, 28 дней
Карма: 443




Цитата (Santehnick @ 18.10.2016 - 12:54)
Причем такое количество, что mongo уже обогнала по популярности postgreSQL.

Может оно так и есть smile.gif Тогда дай, плз, какую-нибудь ссылку на хорошее, по твоему мнению, описалово для Монго. Я с этой БД сейчас не работаю, но она есть у нас в проекте. Хоть знать буду, хотя бы примерно, что там косячит серверная команда и почему данные выбираются с такой скоростью, будто там сидит человек и копипастит вручную.


--------------------
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
PMICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Invis1ble  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме




******

Профиль
Группа: Эксперт
Группа переписки
Сообщений: 11785
Пользователь №: 23195
На форуме: 6 лет, 4 месяца, 11 дней
Карма: 429

Трезвый :
7 лет, 3 месяца, 11 дней


Что вы со своими гуглами и фэйсбуками носитесь, у них совершенно другие требования и ресурсы по сравнению с 99.9(9)% проектов biggrin.gif


--------------------
PMПисьмо на e-mail пользователюСайт пользователя
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Ron  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 1043
Пользователь №: 41686
На форуме: 1 год, 3 месяца, 26 дней
Карма: 13




Ну так надо же надеяться что проект вырастет в Google или Facebook, как вы непонимаете!!! biggrin.gif
http://coub.com/search?q=%D0%BD%D0%B0%D0%B...%B8%D0%B7%D0%BE
Поэтому нужно каждый раз строить немасштабируемый проект на масштабируемой и почти всегда неудобной СуБД. Потому что построить по-настоящему полностью масштабируемый проект from scratch безумно дорого, и так никто не делает.



--------------------
Жду 5.11.2017
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:

Опции темыСтраницы: (3) 1 2 [3]  Ответ в темуСоздание новой темыСоздание опроса