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
Devcon 2020 Goes Virtual! LEARN MORE >

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

Database design question

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
    #1

    Database design question

    What is the best way to handle this.

    Does it make sense to have one database with many tables ands sets? For example:

    Table Big Job
    15 sets
    35 tables
    25 forms

    Or would it be better to have multiple smaller databases with fewer sets and tables/forms in each.

    However; all the tables are in a sense related and would be used by the tables and forms in the other databases.

    What would you do?

    Ron
    Alpha 5 Version 11
    AA Build 2999, Build 4269, Current Build
    DBF's and MySql
    Desktop, Web on the Desktop and WEB

    Ron Anusiewicz
    Tags: None
    #2
    RE: Database design question

    Ron,

    "Does it make sense to have one database with many tables ands sets?"

    I wouldn't preach to anyone but that is what I do. Lots small, specific sets rather than a few massive ones.

    And the numbers you mention do not seem that large for a single database.

    Bill
    Bill Hanigsberg

    Comment

      #3
      RE: Database design question

      If you are going to inter-relate much of the information in the tables, then you want one large database. Otherwise you will be cross-referencing directories to connect all the little databases, which can cause problems if you want to move your database.

      If the data is independent of each other, then each data set should be in a separate database. I am using Alpha's definitions here.

      One of the major advantages of a relational database is that you can slice and dice your information as much as you want.

      Most people recommend have many specific SETs, however, to make debugging easier and lessen the chance of index corruption.

      Mark

      Comment

        #4
        RE: Database design question

        Ron,

        As Einstein said, "Make it as simple as possible, but no simpler."

        In some cases, you might find managing smaller databases easier. In fact, until you mentioned it, I had neglected that possiblity, which might work for me. But, by contrast, the project I'm working on consists of nearly 200 tables and sets and nearly 200 forms with, I think, over 200 functions and scripts. And uncounted xdialogs.

        I think if I were going to use separate databases, I would probably opt for keeping them in the same directory, which may negate some of the advantages (maybe). But that way, if they weren't completely discrete (say two of the databases shared a table), adding the new table in would be fairly easy. (Plus, I've seen enough messages on the board here with people having trouble keeping their directory structures straight to make me not want to wrestle with it.)

        One disadvantage I can is that if you need to use a function in one database that resides in another, you have to, uh, attach a library. (That really only makes me nervous because I haven't done it.)

        An advantage might be that a smaller database is less prone to corruption, and it could certainly be faster to compact.

        You might keep it all as one database, and revisit the question after working with it for a while.

        ===Blake===

        Comment

          #5
          RE: Database design question

          Ron,
          I wouldn't hesitate to put that and much more in a single database.Your app is by no means large in terms of number of tables and sets.I have some apps ( databases ) with several hundred tables and sets, hundreds of forms and reports and at least as many global scripts or functions. Opening the database takes a little bit of time as would refreshing the control panel. As far as I know, the only time refreshing the control panel is really necessary is when using the adhoc browse addin.
          Good naming conventions help keep things organized. Constant backups keep things safe.The only reason I could think of for using multiple databases is if you were trying to market a package in modules. Even then, I'm not sure it's necessary.
          John

          Comment

            #6
            RE: Database design question

            Blake,

            I wouldn't worry about adding libraries. I've been doing it for quite awhile with no problems.

            Now, in v5, I've gone to creating my own compiled .aex files which I use as appropriate with each application. I find these advantageous because there is a tendency when attaching other libraries to update the 'local' copy of the library but not the original. This happens because all the scripts in an attached library can be edited from the control panel. Since .aex files are compiled, they are not visible in the control panel and updating a 'local' copy is not an issue - updates must be done in the 'parent' application.

            On my own system, all of these .aex files are loaded in the A5v5\Addins_installed folder. The names are fairly self-explanatory: AIMS_StdFuncs.aex, AIMS_StdScripts.aex, AIMS_Security_Funcs.aex, AIMS_Backups.aex. Then, of course, there are my various developer addins that have no use for the normal user - AIMS_Developer_code.aex, AIMS_Script_format.aex, Delete_operations.aex, and AIMS_Group_Format.aex.

            By keeping these in .aex files separate from the regular global scripts, I can update one file and distribute it to everyone without any need to edit individual applications. I've lost count of how many times I've either fixed a problem or added a new feature or function/script to these files. I'm always careful to keep them backward compatible but, other than that very minor issue, it makes upgrades much easier.

            Comment

              #7
              RE: Database design question

              We have an enormous system where the need for separate databases actually exists. Our information, in most cases, is distinct per application, but we needed to present a common front-end. 35 sets is fairly small, and one database can handle that with no problem. The number of tables and forms you describe is certainly not a problem.

              Tom

              Comment

                #8
                RE: Database design question

                I agree that it's probably not necessary.

                However, I do find the current app harder to get around in than a smaller app would be. There's a lot of extraneous scrolling. (All A5 apps are harder to get around in than I'd like, but the problem is compounded as the app gets larger.)

                So, what's a "big" database? :-)

                Comment

                  #9
                  RE: Database design question

                  I wouldn't worry about adding libraries. I've been doing it for quite awhile with no problems.

                  That's reassuring.

                  Now, in v5, I've gone to creating my own compiled .aex files which I use as appropriate with each application. I find these advantageous because there is a tendency when attaching other libraries to update the 'local' copy of the library but not the original. This happens because all the scripts in an attached library can be edited from the control panel. Since .aex files are compiled, they are not visible in the control panel and updating a 'local' copy is not an issue - updates must be done in the 'parent' application.

                  Ye gods. So when you import a library, you actually get a copy? =That's= critical to know. When you update the original, do you have to reimport?

                  Your solution sounds like a good one. Do you create empty databases and just add functions--is that how you set up your libraries?

                  Comment

                    #10
                    RE: Database design question

                    So when you import a library, you actually get a copy?
                    When you attach a .al* library from another database(this was possible in v4 also), that library is treated just like the scripts in the 'parent' database. They are visible and can be altered unless password protected.

                    Do you create empty databases and just add functions--is that how you set up your libraries?
                    Well, that was the intention. However, I've usually ended up adding some test tables so I could check out the results of my work.

                    NOTE: Another really nice feature is the Import/Export options for scripts.
                    1. This is a good script backup method.
                    2. Sometimes the database ends up with little 'extras' that I don't want to be included in the .aex file so I just export all scripts and functions, delete the unwanted 'extras', create the .aex file, and import everything back in again.

                    Comment

                      #11
                      RE: Database design question

                      When you update the original, do you have to reimport?
                      That depends. If you have attached directly to the original, re-attaching is not necessary. (This type of library is not imported; it's attached.) However, I was using these as standard libraries - in fact, the v4 library was actually called Std_code.AL* - so they were usually copied to the customer's folder and attached from there so the customer's installation would still be able to locate the library because it was still in the application folder. The problems arose when I updated one application but didn't do it to others and later couldn't figure out which one was 'correct'.

                      The initial changes may take slightly more time with the .aex files but the overall efficiency is much better.

                      Comment

                      Previous template Next
                      Working...
                      X