Access Basic

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 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

EditText of this page (last edited June 18, 2013) or FindPage with title or text search