• jlexer
  • NEWBIE
  • 0 Points
  • Member since 2009

  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 1
    Questions
  • 1
    Replies

I am looking for help to determine whether Force.com is a good fit for a large-scale Enterprise application.  There are several questions that I have the I have not been able to locate the answers on my own:

 

 

  1. Is there a threshold where the Force.com database may not be a good choice where traditional enterprise relational databases will be a better choice?  The app I am tasked with building will be terabytes of data.  If we imagine the industry of widget manufacturers, this app will serve the to track all the wholesale sales of widgets for every manufacturer.  All widget distributors will load their sales history and the manufacturers will reimburse the distributors for reaching qualifying sales quotas.   The typical user will be a manufacturer that will run reports that will query data at a national level for all distributors in the country.  The data queried would be millions ofrecords.  How can I quantify that theForce.com database is as robust as the major relational databases?  Are there whitepapers that compare the performance of the Force.com db vs. the standard relational db’s?
  2. I am unclear of what the pricing structure would be to my end users.  When I create aForce.com app that has no relation to the Salesforce.com  CRM product, what is the per user costs to Salesforce.com?  What are the storage costs to Salesfoce.com?  This app will likely have a disproportioned number of users to storage.  That is, a small number of users but a large amount of data. I need to project these storage costs to determine in advance the true pricing model for the end users. Also, unlike other compute cloud providers, I have seen no mention of bandwidth or compute costs.  Please confirm it is correct that there are no bandwidth or compute costs for a hostedForce.com application?  I have spoke with a Business development person, but she was non-technical and was unable to answer any of these issues.  

 

  • October 19, 2009
  • Like
  • 0

I am looking for help to determine whether Force.com is a good fit for a large-scale Enterprise application.  There are several questions that I have the I have not been able to locate the answers on my own:

 

 

  1. Is there a threshold where the Force.com database may not be a good choice where traditional enterprise relational databases will be a better choice?  The app I am tasked with building will be terabytes of data.  If we imagine the industry of widget manufacturers, this app will serve the to track all the wholesale sales of widgets for every manufacturer.  All widget distributors will load their sales history and the manufacturers will reimburse the distributors for reaching qualifying sales quotas.   The typical user will be a manufacturer that will run reports that will query data at a national level for all distributors in the country.  The data queried would be millions ofrecords.  How can I quantify that theForce.com database is as robust as the major relational databases?  Are there whitepapers that compare the performance of the Force.com db vs. the standard relational db’s?
  2. I am unclear of what the pricing structure would be to my end users.  When I create aForce.com app that has no relation to the Salesforce.com  CRM product, what is the per user costs to Salesforce.com?  What are the storage costs to Salesfoce.com?  This app will likely have a disproportioned number of users to storage.  That is, a small number of users but a large amount of data. I need to project these storage costs to determine in advance the true pricing model for the end users. Also, unlike other compute cloud providers, I have seen no mention of bandwidth or compute costs.  Please confirm it is correct that there are no bandwidth or compute costs for a hostedForce.com application?  I have spoke with a Business development person, but she was non-technical and was unable to answer any of these issues.  

 

  • October 19, 2009
  • Like
  • 0