Построение архитектуры Базы данных

В Salesforce ты не работаешь с базой данных :).
Тебе не надо думать о ее нормализации и оптимизации. За тебя уже все сделали за красивой обложкой Salesforce.
Поэтому основной принцип - делай так, чтобы было удобно пользоваться и объекты были максимально похожи на объекты из реальной жизни. Главная твоя забота не вылезти за пределы лимитов, тогда можешь смело себя называть Database архитектор (с приставкой Salesforce).

зы. Буквально пару минут назад писал в соседней ветке как Salesforce расслабляет :) и вот опять.

[quote="Dmitry Shnyrev"]В Salesforce ты не работаешь с базой данных :).
. Главная твоя забота не вылезти за пределы лимитов, тогда можешь смело себя называть Database архитектор (с приставкой Salesforce).[/quote]

подозрительно просто...

а как же те проекты которые исполоьзуют force.com только как базу данных? у них тоже никаких правил, кроме простой человеческой логике и лимитов?

А кто использует force.com "только как базу данных"? :) Не слишком ли расточительно?

[quote="Dmitry Shnyrev"]А кто использует force.com "только как базу данных"? :) Не слишком ли расточительно?[/quote]

а Herouki как работает? 

я думал, что SF выгодно продавать себя и как удобную базу данных для сторонних проектов. Но как организовать работу с этой базой данный? по РЕСТУ или СОАП апи? непонятно

Вот, когда-то разбирался сколько будет стоить Salesforce.
[quote]Data Storage (1GB + дополнительное место за каждую лицензию) — используется для хранения вашей базы данных. При чем, в Salesforce принято что 1 запись в базе данных занимает 2Kb, т.е. стандартного места вам хватит на 500 000 записей. Дополнительный 1Gb встанет вам в 3000$ каждый год. [/quote]
500 000 записей!!! любой "боевой" проект с трудом уложится в эти цифры и использовать Salesforce в качестве базы данных уж точно мало кто решится. Его покупают за функционал из коробки и чтобы голова не болела по поводу оптимизации базы данных :)

[quote]я думал, что SF выгодно продавать себя и как удобную базу данных для сторонних проектов.[/quote]
Очень неправильная точка зрения. Они продают функционал, который позволяет скрыть от вас базу данных. Чтобы просты пользователи могли пользоваться, а не гуглили в поисках "как запустить apach и базу данных и развернуть приложение"
Если интересно, то был когда-то (и сейчас есть), но очень не популярный продукт от Salesforce (вы наверное про него даже не слышали), называется [url=http://database.com]database.com[/url] (даже доменное имя какое выкупили). Вот это и голая база данных Salesforce, которую пытались продвигать, но по ходу не пошло.

!!! :) о, даже уже и нет этого продукта. Закрыли по ходу и редирект стоит на рекламу Salesforce1. А помню, я с ним игрался, было интересное решение. Тот же Salesforce, но только без всего, с одними голыми кастомными объектами и API.

[quote]а Herouku как работает? [/quote]
Очень просто - пишешь свое приложение на java, python, ruby, nodejs. Заливаешь на Heruku, запускаешь и все!
Это своего рода преднастроенный сервер с базой данных (Postgres), который умеет автоматически подстраиваться под нагрузку если простыми словами. В общем что-то среднее между Salesforce и VPS

[quote="Dmitry Shnyrev"][quote]а Herouku как работает? [/quote]
Очень просто - пишешь свое приложение на java, python, ruby, nodejs. Заливаешь на Heruku, запускаешь и все!
Это своего рода преднастроенный сервер с базой данных (Postgres), который умеет автоматически подстраиваться под нагрузку если простыми словами. В общем что-то среднее между Salesforce и VPS[/quote]

А Амазон как свои облачные сервисы предлагает? или там покупаешь только вирт сервер, а потом его еще и настраивать нужно (то есть "заливаешь и все!" не работает)?

[quote="Dmitry Shnyrev"]В Salesforce ты не работаешь с базой данных :).
Тебе не надо думать о ее нормализации и оптимизации. 

зы. Буквально пару минут назад писал в соседней ветке как Salesforce расслабляет :) и вот опять.[/quote]

Всегда нужно думать о нормализация и оптимизации ) Иначе происходит такое, что даже индусам не снилось. Много есть примеров, где даже не соблюдена 1 нормальная форма.

[quote="Art Vegas"]

Всегда нужно думать о нормализация и оптимизации ) Иначе происходит такое, что даже индусам не снилось. Много есть примеров, где даже не соблюдена 1 нормальная форма.[/quote]

вот-вот, если нет чего говорить о SF базе данных в целом, давайте поговорим о типичных косяках.

или о каких-то шаблонах ДБ проектирования со схемами  связей и объектов.
например в упражнении по создании приложения для HR в воркбук Фундменталс - было создана ДБ (объекты и связи) с такой схемой, что сразу и не догадаешься так сделать.

[quote]А Амазон как свои облачные сервисы предлагает? или там покупаешь только вирт сервер, а потом его еще и настраивать нужно (то есть "заливаешь и все!" не работает)?[/quote]
Да, именно. На амазон ты покупаешь машины и все устанавливать и настраивать нужно вручную. Пока в плане цены VPS более привлекательны. Хотя если денег не жалко, то стоит смотреть в сторону Амазона для приличного проекта. Плюс Амазона в том, что у него очень много профессиональных сервисов, которые помогут облегчить жизнь крутого проекта. Но это уже высший пилотаж - администрирование Amazone это целая наука и это область осваивают годами, точно также как мы Salesforce

[quote="Dmitry Shnyrev"]Плюс Амазона в том, что у него очень много профессиональных сервисов, которые помогут облегчить жизнь крутого проекта. Но это уже высший пилотаж - администрирование Amazone это целая наука и это область осваивают годами, точно также как мы Salesforce[/quote]

у меня есть догадка - на амазоне размещаются проекты напрямую связанные с е-бизнесом и как результат торгующие (перепродающие) своим товаром и на амазоне.ком. В таком случае обеспечивается тесная интеграция с торговой площадкой амазона.

[quote]у меня есть догадка - на амазоне размещаются проекты напрямую связанные с е-бизнесом и как результат торгующие (перепродающие) своим товаром и на амазоне.ком. В таком случае обеспечивается тесная интеграция с торговой площадкой амазона.[/quote]

Ошибочная догадка. Сервисы амазон и онлайн магазин - это разные и не связанные области. Если ты будешь хостить свои приложения на виртуальных машинах Amazon это никак не поможет тебе с работой с торговой площадкой. Это просто виртуальные сервера. Вот типичный пример - сервис Dropbox работает на базе Amazon (крутится, хранит файлы).

Всем привет!

хочу продолжить эту тему и обсудить такую ситуацию:

вижу кастомный объект, на нем в бесконечной череде других полей идет описание какого-то "персонажа" - имя, фамилия, тел, емайл.

А говорю БА, кто создал этот объект: "это типичная Контактная инфа, ее нужно хранить в Контактах, а на записи только ссылаться на нее". Он отвечает: "Да не, все нормально, пусть тут будет".

Ну и вопрос для вас: а вы как думаете, всегда ли нужно типичную контактную инфу (а может и Эккаунтную) ложить в Контакт, или есть ситуации, когда контактная инфа может идти в такие "глухие" кастомные поля?


и есть еще не вопрос, а ситуация. 

Она частично связана с предыдущим вопросом, но все же о другом. 

часто на сайтовых страницах создаются записи на которых есть лук-ап на эккаунт или, что чаще, на Контакт. и проблема в том, что сторонние сайтовые пользователи  не могут разобрать как работает лукапный функционал: они не могут найти свой контакт и тем более не могут создать на-ходу новый. Поэтому на сайтовых страницах выводится не лук-ап поле, а поля контатного объекта, и в контроллере в момент сохранения записи идет поиск соответствующего контакта или создание нового и запись его в лук-апное поле основной записи.

Что вы думаете о таком подходе?

По поводу хранения контактной информации - конечно прежде всего необходимо хранить человека в объекте контакт, я думаю это правило номер один. А вот дальше начинаются частности. Если у тебя отдельное приложение, которое должно хранить сущности "человека", но они не связаны с теми людьми, которые хранятся в объекте Contact, то лучше использовать свой кастомный объект. НО то что ты описал - хранить части (поля) от контакта в других объектах, например Заказ, то это уже плохо. Это уже противоречит законам нормализации реляционной базы данных (помню когда-то читал теорию, там были первый, второй и третий вроде законы, вроде). 
Вообще база данных должна повторять реальный мир по максимуму - есть пользователи, например заказчики, пусть это будут контакты. Есть продавцы, пусть это будет объект Manager. И так дальше, Заказы, Продукты, Логи. Все что в реальной жизни можно обособить все в отдельный объект. Но смешивать - это зло!
По поводу совмещения данных в одну сущность есть такое направление NoSQL базы данных, но я думаю они здесь не причем.

[quote="Dmitry Shnyrev"]Вот, когда-то разбирался сколько будет стоить Salesforce.
[quote]Data Storage (1GB + дополнительное место за каждую лицензию) — используется для хранения вашей базы данных. При чем, в Salesforce принято что 1 запись в базе данных занимает 2Kb, т.е. стандартного места вам хватит на 500 000 записей. Дополнительный 1Gb встанет вам в 3000$ каждый год. [/quote]
500 000 записей!!! любой "боевой" проект с трудом уложится в эти цифры и использовать Salesforce в качестве базы данных уж точно мало кто решится. Его покупают за функционал из коробки и чтобы голова не болела по поводу оптимизации базы данных :)[/quote]

500000 записей это не совсем хорошо для Salesforce. Надо понимать что Salesforce это не data warehouse в общем случае. В случае, если Master-Details нежелательно иметь на Detail стороне лучше не держать больше 10000 объектов (почитайте про data skew)

Спасибо за совет про data skew.
Но все таки несмотря на data skew места все равно маловато. Вот типичный пример - сейчас работаю с проектом на SF где в Activity записываются история работы Call Center. Call Center небольшой, всего на 3 оператора, но за 3 месяца работы только на эти записи ушло около 30% Data Storage. И это всего лишь пример. Понятно что с "старые" звонки можно удалять, но таких же объектов можно придумать кучу.
В принципе это тоже не проблема, уже давно подумываю на этот случай сделать интеграцию с Heroky и периодически сливать туда устаревшие данные, а также прикрутить поиски по ним их Salesforce. Я думаю это будет простое решение проблемы :) 

[quote="Dmitry Shnyrev"]Спасибо за совет про data skew.
Но все таки несмотря на data skew места все равно маловато. Вот типичный пример - сейчас работаю с проектом на SF где в Activity записываются история работы Call Center. Call Center небольшой, всего на 3 оператора, но за 3 месяца работы только на эти записи ушло около 30% Data Storage. И это всего лишь пример. Понятно что с "старые" звонки можно удалять, но таких же объектов можно придумать кучу.
В принципе это тоже не проблема, уже давно подумываю на этот случай сделать интеграцию с Heroky и периодически сливать туда устаревшие данные, а также прикрутить поиски по ним их Salesforce. Я думаю это будет простое решение проблемы :)[/quote]
Согласен, это наверное самый простой путь. Посмотрите вот на это, но работает почти из коробки, но вроде бы стоит денег https://www.heroku.com/connect. В CTI Integration это постоянно случается что Call Log'и сжирают место.