1 2 Previous Next 29 Replies Latest reply on Apr 12, 2017 12:22 AM by Fred(CH)

    Dear FMINC

    dataWolf

      Dear FMINC

      Many of us make large databases and they become unwieldy to manage in Filemaker and make me want to switch to a different system just so I can manage the internals. Please add the following ASAP:

      1) ability to group fields into folders. This would be so massively helpful. This way I could close folders and not have to see fields which are important but rarely administrated so are visually clutter and make my job difficult. Also it would avoid creating additional tables just to try to separate chunks of related fields. To compartmentalize data is good database design, but a pragmatically bad idea in Filemakie because even indexed fields in related tables are super slow once you get the record count up there, especially over the internet. I've watched SQL databases do queries in less than a second that takes FM several minutes.

      2) Comments on Scripts, the way there is on Fields. This would be so wonderfully helpful. I've got so many scripts. I don't know what half of them do or what body of work they were used for.

      3) The ability to list relationships, and add comments, and folders. Relationships are really unwieldy. I've got 40-70 relationships per file and it's like walking through a haunted deserted Winchester Mansion with mystery rooms most of which is forgotten cobwebby unknown possibly critical, possibly useless and we'll never know (until we delete the critical ones we THOUGHT were useless) - and I'M the person who wrote this stuff (but can't document it!)

      4) Change name of program. Most programs "Make" "Files". What is unique about your product and how would I recognize it and why would I want to buy it? Why not something more marketable such as "Super Ultra Mega KickAss WYSIWYG GUI Database Designing Creating and Managing Utility" But you can't truthfully call it that until you make the changes I requested. Thank you.

        • 1. Re: Dear FMINC
          Johan Hedman

          dataWolf

           

          Add this to Product idea

          Product Ideas

           

          Divide each point into on idea

          • 2. Re: Dear FMINC
            Markus Schneider

            as Johan mentioned: There is a 'product ideas section'

             

            there are methods that can help:

             

            1

            field names must be unique. With folders (can be 'closed'), it could be less clear. Further on, a database should have a minimum set of fields (normalisation...)

             

            2

            Comments are inside the scripts, as in every programming language / scripting language. Scripts can be grouped into folders, we are using folder names for a first overview

             

            3

            2emPower Plugin (Developer's assistant) makes searches possible, almost everywhere. Yes, will cost money - but saves time. Further on, one can group relationships into sections (in the graph) and add comments. For better handling, use 'anchor buoy' methods (among others)

             

            then...

             

            4

            'FileMaker' is a brand. For more than 30 years... don't touch that! It was a word-combination of 'Microsoft File' and 'PageMaker' (2 well known applications at that time).

             

            (-:

            • 3. Re: Dear FMINC
              wimdecorte

              dataWolf wrote:

               

              Dear FMINC

              Many of us make large databases and they become unwieldy to manage in Filemaker and make me want to switch to a different system just so I can manage the internals. Please add the following ASAP:

              1) ability to group fields into folders. This would be so massively helpful. This way I could close folders and not have to see fields which are important but rarely administrated so are visually clutter and make my job difficult. Also it would avoid creating additional tables just to try to separate chunks of related fields. To compartmentalize data is good database design, but a pragmatically bad idea in Filemakie because even indexed fields in related tables are super slow once you get the record count up there, especially over the internet.

               

              Intrigued by this.  Can you put some numbers next to these to give some perspective?  How large are the databases.  And how many fields are we talking about for those unwieldy tables?

               

              Data normalization is the norm for any database, including FM.  Denormalization can certainly be used to increase performance but in my experience normalization in FM is not as painful as you describe; certainly not to the point that I would wish to avoid creating additional tables or to label normalization a bad idea as a blanket statement.

              • 4. Re: Dear FMINC
                fmpdude

                To the OP:

                 

                Normalization: I would suggest using a real ERD tool that will integrate with FMP in real time (that is, with your LIVE FMP database) to read or write the diagram from/to a FMP database. Tools like the inexpensive like "SQL Editor" will integrate DIRECTLY with your FMP database.

                 

                Don't think of the Relationship Graph as an "ERD Tool".

                 

                Bottom line: you should have a normalized database design before you think about FMP or any database implementation.

                 

                HOPE THIS HELPS.

                • 5. Re: Dear FMINC
                  Vincent_L

                  Denormalization can certainly be used to increase performance but in my experience normalization in FM is not as painful as you describe; certainly not to the point that I would wish to avoid creating additional tables or to label normalization a bad idea as a blanket statement.

                  I'm not the OP, but I've at least 200 Denormalization /cache fields in my main table, because I and my users constantly use them (search, sorts). Before they were normalized but performance sucked.

                  I wish I could group them in folders (and I wish related fields where not so slow in filemaker)

                  • 6. Re: Dear FMINC
                    dataWolf

                    1a) I don't understand why you are saying this. Are you saying if fields were grouped into folders, and you were trying to use a non-unique name, it would be difficult to know that was happening? It would be exactly the same as now, the create button would be disabled and no indication of what the problem is. I have 10 pages of fields, folders would not make it anymore difficult. What should happen in both scenarios, is a message appear saying "Field name already in use".

                     

                    1b) I think you don't mean "minimum" number of fields I think you mean "minimal" and with certain projects, minimal could mean thousands. And I've never heard normalized to mean "low number" of anything. To me, "normalized" means un-concatenated, having the data in as atomic, or simplest conceptual blocks as possible. But count is irrelevant.

                     

                    2) Maybe I did not describe that well enough. Yes I think the comments inside the scripts are great. I'm saying I have many scripts and some are important and the name says what they do, but I don't remember why they were created. I know of some that are very simple, such as navigating to a layout, but they are important and heavily used but it's not obvious. On the fields I've taken to adding notes into the second line to indicate conceptually what it's for, or used in what scripts or layouts. Kindof like the DDR but realtime and a lot less clunky.

                     

                    3) Reading about anchor-buoy sounds as though it adds pros and cons and involves recreating my ERD which I'm not interested in doing. Especially as some say, it gets similarly as unwieldy in esoteric TO names, and some restrictions which I don't understand. Can someone explain it in one sentence? Does it replace relationships with one one relationship that relates everything and you just use that one complete match? I don't understand it.

                     

                    4) Okay I'll accept that because I don't understand marketing . Though it does seem even large corps change names when they merge, or just retain FM as the subtitle name for ten years then drop it. But as I said I don't understand marketing.

                    • 7. Re: Dear FMINC
                      dataWolf

                      too bad it doesn't give a current record count, so you could see what areas need to perform well

                      oh zeus! it doesn't show field count? omfg

                       

                      membership 438 fields 172k records

                      appeal 105 fields 712k records@

                      cultivation 13fields 408k records

                      sust 153 fields 43k records

                      xaction 218 fields 1,425k

                       

                      The biggest problem is that memerships have susts and susts have many xactions, and the membership screen shows oldest sust, newest, highest pledged, highest fulfilled, and all that crunching takes a really long time when remote. like four minutes to show one record.

                      Also, adding a record to xaction takes a long time. I suspect because there are probably 40 indexed fields and when a record is added, it has to create all indexed entries, even if they are blank?

                      • 8. Re: Dear FMINC
                        philmodjunk

                        With regards to 3) The biggest take away on that method is not the naming convention you might or might not use, but the practice of breaking up your table occurrences into smaller groups with a clearly documented (via text box) general purpose for each group. With large solutions and multiple users, setting up an "anchor" occurrence that represents a specific layout or group of similar purpose layouts is a useful part of making up such groups.

                        • 9. Re: Dear FMINC
                          dataWolf

                          Denormalization - Membership included Demographic information. The membership field list was too hard to read, so i moved the fields about demog to a Demog table. Now I regret that because even on the membership screen, it is say .10 second slower to search for the indexed first name in the other table. But add last name, and address info, and bad address exclusions, and multiply this on all the records when doing a search, and I have already to decide to move Demog back into the Membership table because the slowdown is not good. It's noticeable on the LAN, and it is quite slow over the WAN when searching on multiple stored fields through a relationship. record count is 172k records in each table.

                          Perhaps I should do a test with only stored records and see how fast that is. Perhaps it's not those indexed fields, perhaps it's something else. Note that the server is on west coast and remote access is east coast.

                          • 10. Re: Dear FMINC
                            dataWolf

                            ok thanks i'll check it out. oops it's only mac, i have a windows at home. have to try it at work. but i also work at home...

                            • 11. Re: Dear FMINC
                              dataWolf

                              Thanks. I did NOT get that from reading three documents without actually trying it.

                              So it's like a folder, or a box around them.

                              I already do that by default, putting similar TOs in a neighboorhood and having other groupings in other areas. I don't understand how the anchor is done visually, but if I want to know more I guess I'll have to work more with the material. Thanks at least for that summarization.

                              • 12. Re: Dear FMINC
                                wimdecorte

                                You may want to consult with someone who uses A/B a lot; it would only take 30 minutes to run down a good setup and explain the benefits and weaknesses.

                                • 13. Re: Dear FMINC
                                  Malcolm

                                  A part of the reason for normalising is to reduce the data load in any single table. For example, if your solution needs to keep a history of addresses, you don't want to have to add new fields for street, city, state to your table everytime someone moves to a new address.

                                   

                                  Having normalised the data for storage doesn't mean that it is compulsory to use information derived dynamically from raw data for every single action.

                                   

                                  You might want to add a table called "memberSusts" that contains the fields oldest, newest, highest pledge, highest fulfilled. Those fields could be updated whenever a new Sust is added. That action will be quick because you are testing the values in the current record against the values in the single "membeSusts" record. Then, when you display the Sust figures you are not having to process 43k records to get the max/mins for your dashboard. You simply display the stored values in a record that has a one to one relationship. If that performance still sucks, put those fields into the same table.

                                  • 14. Re: Dear FMINC
                                    beverly

                                    Who is to say what is "normal"-ization? Keep in mind with FileMaker, we have

                                    • Value Lists
                                    • Multi-line Keys
                                    • Summary Fields and report parts
                                    • List functions
                                    • No arrays or structs
                                    • No temp tables like with a SQL call
                                    • Virtual table/list and or export+import to get data we would not otherwise get
                                    • ExecuteSQL() function to SELECT
                                    • Variables and functions and scripts to "gather" or "parse out" data

                                    (probably more)

                                     

                                    Reports are not always easy to get what we want without a little work. Sometimes we are strictly Normalized, sometimes we have flat tables composed of fields (columns) & records (rows) that may pull from related (just because we need a report not otherwise available), sometimes we use a method called EAV (Entity-Attribute-Value) - not SQL (non-SQL), & sometimes we have to export (or use a web publishing and/or other app) to further mangle (er manage) the data in a way that a client needs.

                                    my dos pesos,

                                    beverly

                                    1 2 Previous Next