Access Basic is a derivative of Microsoft VisualBasic used for the early versions of the Microsoft Access desktop database product. Access has since been enhanced to use VisualBasic for Applications (VBA) instead. ''"Enhanced?" Yeah right.'' [It was certainly enhanced compared to Access Basic, which was notably dire. It was almost as bad as ExBase.] ''Fooey! ExBase was far more compact for table-chomping than Access. ExBase was designed by people who don't like to type. MS relies on Auto-Bloat to complete verbosity for you. And you could easily use any text editor of your choice.'' [What is "table-chomping"? It was designed by people who don't like to type? Really? ExBase development required an inordinate amount of code to create even small applications -- say those with between 10 and 500 tables -- due to the lack of reasonable support for code maintenance and re-use. Access wasn't (and still isn't) much better, but at least it was better.] There's not a lot of room for reuse for smaller custom biz applications. Custom biz logic for the most part is not reusable. Most "reuse" I do now is because the HtmlStack sucks eggs such that I have to reinvent UI shit that should have been standardized in the mid 90's. Excess reuse is often a tool smell. [There's a lot of room for reuse of user-interface and reporting elements across a suite of applications, and "custom biz logic" is frequently re-used across multiple applications. ExBase made re-use so slow and awkward that its developers persist to this day in the mistaken belief that there's not a lot of room for reuse in "custom biz applications".] A small app with 500 tables? Sounds like poor table factoring. [Your condescension does nothing to disguise your obvious ignorance of enterprise application development. 500 tables '''is''' a small application, compared to medium-sized applications with roughly 500+ to 5000 tables and large ones with 5000+ tables. These are designed and implemented by experienced developers who don't make beginner's mistakes like "poor table factoring". Obviously, ExBase and MS Access are not appropriate for anything above the tiny to small scale of enterprise development, typically workgroup applications.] Generally I'd consider a small well-designed app to have about 5 or fewer tables, 6 to 20 for a medium-sized app, and 21 to 50 for large apps. If the large app has more than 50, I suspect poor factoring in play, which is often the case with legacy systems that cannot refactor without breaking lot of existing stuff. Thus, it's not necessarily about being "bad designers", but rather inherent growth problems akin to the FragileBaseClassProblem or the ModuleDependencyProblem. Performance issues also sometimes dictate semi-ugly schema designs, at least when the app was born. But if we don't have to care about legacy or performance issues, within reason, then the numbers I gave I believe to be realistic the majority of the time. I'd be happy to evaluate a schema with 500+ tables as long as you are willing to answer domain questions about it. -t * ["21 to 50" tables might be "large apps" '''to you''', but please don't confuse that with enterprise application scale. I don't have a schema with 500+ tables that I'm at liberty to distribute, but I've put a sample small schema with a little over 100 tables -- realised as a Microsoft Access database (I guess it's large for Access) -- at http://www.armchair.mb.ca/~dave/Examples/EDM.accdb It's conceptually illustrative -- differing from larger schemas in scale but equivalent in approach -- and I'm happy to answer domain questions about it, particularly those related to your assertion that if "the large app has more than 50, I suspect poor factoring in play..."] {"21 to 50 for large apps?" That's so ridiculous I'm still laughing. One app I worked on that was on the smaller side of medium had 300 tables. The current app I'm working on easily has over 5000. I've heard of databases with over 700,000.} ToDo or EditHint: Move to TableQuantityVersusAppSize ---- CategoryVisualBasic CategoryDatabase