Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Schemas, multitenancy, SAAS, fundamental design questions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Schemas, multitenancy, SAAS, fundamental design questions

    Have been developing a multi-tenancy application for years now and have yet to put in production yet.
    I am now getting cold feet over the basic design of the backend Postgres database.

    Each table has a tenantid column which Alpha 5 filters on for each and every dialog, grid, query, report, etc. based on the user login information. This is the fundamental one database, one schema design for multi-tenancy. Works fine and I get it.

    After some pretesting and short starts, I am now concerned about performance down the road for some of the tables, particularly timesheet and workflow tracking that will have hundreds of thousands of entries in each table potentially from each tenant. This won't be an Alpha 5 issue, but a Postgres performance issue. Since I have no practical way of knowing how many entries will be made or even how many tenants will use the system, I am gravely concerned of building my castle on sand when my app takes off like FaceBook.

    After reading many of the posts on this forum and elsewhere regarding multi-tenancy, I wonder if I should be going back to the one database/tenant design and use dynamic data connections instead. Nearly everybody recommends against this because of maintenance/update/backup issues going forward, but seems like the best solution for scalability, security (no intermixed data), and simplistic programming.

    The real question is my understanding of schemas, particularly in relation to Postgres and the interaction with Alpha 5. I was hoping that schemas could have a master layout of employees, customer, orders, etc. and be able to setup a schema based system that would automatically have grids, dialogs etc. refer to table like this:
    company1.employees
    company2.employees
    company3.employees
    company1.customer
    company2.customer
    ........
    You would then have grids, etc. refer to the table through a dynamic connection that would enable a variable based on the login to interject the <company>.table as a datasource for each grid.

    But, what I can tell of Alpha 5, it refers to the schema tables as:
    employees.company1
    employees.company2
    employees.company3
    customer.company1
    customer.company2
    ......

    #1 So my bottom line understanding/question is, a dynamic data connection only works for a database, not a schema correct?
    #2 Is there something I am missing to be able to assign grids and dialogs dynamically based on the user login?
    #3 If #2 is possible, I assume the same can be done with custom xBasic and reports too?

    Thanks for reading through my long winded question.

    Andy

    #2
    Re: Schemas, multitenancy, SAAS, fundamental design questions

    Don't do #1 or #2 or #3. Just use the same series of grids for all users. It would make no performance impact either way to use different grids and would just make your life harder. Same with Dynamic connections. I believe Pat B uses that method but his client demands it. There is no scale-ability advantage to using multiple databases unless you are maxing out those database connections. The administrative hassle to manage all of those clone-databases would overshadow any small performance perk, if there were any perk.

    I would not worry about taking off like Facebook. If you did that you would have investors and tons of cash and a staff to deal with any data volume problems.
    Steve Wood
    See my profile on IADN

    Comment


      #3
      Re: Schemas, multitenancy, SAAS, fundamental design questions

      Andrew - I'll second what Steve Wood says. I had a customer who also required a separate backend database for each customers. What a pain, and just plain complicated things. My current largest and growing project uses a single database and the very same set of components and pages for everyone -- just gotta make sure all the filters are correct. Way easier to manage, performs just fine (no Facebook-like user base yet...) and is clearly the way to go.

      The most likely bottleneck you'll run into won't be your database or database server, but rather the Alpha Five server. But that's what multiple instances and load balancers are for.
      -Steve
      sigpic

      Comment


        #4
        Re: Schemas, multitenancy, SAAS, fundamental design questions

        Thank you to the two Steves.

        I still am using the same fundamental setup with a tenantid in every table like you set me up with a couple of years ago (Steve Workings)
        As you stated, just have to make sure everything is getting filtered on the tenantid.

        Just a little shell shocked from my testing at my brother's factory and a few hundred thousand entries were in one table over the course of several months of operation. Didn't take much imagination to foresee possible performance issues with that table.

        After reading various articles on the internet, because everything is true on the internet, there were several articles that said multi-tenant databases should use schemas. These were more focused on the security and programming side than the performance side. I wasn't sure if essentially the same amount of data would perform any better in a multiple schema database rather than a single schema database anyway.

        Thank you for your input. I will continue to forge on as before.....need to quit wandering in the internet database articles

        Comment


          #5
          Re: Schemas, multitenancy, SAAS, fundamental design questions

          personally, (and I am no expert) I built and am building a multi-tenant app. My thoughts are one database, many users. Its simplistic and scalable in every sense of the word...multiple schemas = nightmare.

          agreed, if it takes off with a tone of users you will have cash to throw at solutions.

          I would be more concerned with quality of use, and overall usefulness of the app - this in turn will create more users, more feedback and finally a better app and end user experience.
          This is the goal.
          NWCOPRO: Nuisance Wildlife Control Software My Application: http://www.nwcopro.com "Without forgetting, we would have no memory at all...now what was I saying?"

          Comment


            #6
            Re: Schemas, multitenancy, SAAS, fundamental design questions

            Been doing this for years as have many others.
            main app is a car app where several dealers in a group have their specific dealership information.
            Goes like
            dealer which has a field in all tables that matter
            each user has their own area for customers, yet management can access all at once and owner(of all the dealerships) can access all dealerships of all users records in one dealership or specific users in any dealership or go to one specific record.
            So this one is muli-tenant inside a multitenant.

            As all have stated, It is a tremendous amount of work.
            Dave Mason
            [email protected]
            Skype is dave.mason46

            Comment


              #7
              Re: Schemas, multitenancy, SAAS, fundamental design questions

              Andrew - Row counts in SQL tables generally should not present much of a performance issue, but each "issue" really depends on the purpose and function of the particular table and records.

              I have a handful of tables receiving 1 million records per year right now, and that will increase as our user base grows.

              Another table for a different customer currently holds 5 million accounting journal records. We do a lot of evaluation, calculation and manipulation with that, and I'm very very pleased with the performance.

              What Charles says - make the user interface satisfying; the SQL backend performance is probably the least of your worries. Javascript and CSS are probably of greater importance. If you begin to run into a problem with Xbasic manipulating your data too slowly, time to look into stored procedures.
              -Steve
              sigpic

              Comment

              Working...
              X