Database Architecture – Is Continuous Table Creation and Deletion a Flaw?

Let's get a few things straight:

1. Interactive scripting and static languages aren't mutually exclusive. F# and Haskell both have REPL interfaces.
2. Dynamic languages and high performance aren't mutually exclusive, though some optimizations are. JavaScript runs pretty damn fast on most browsers nowadays.
3. Even in dynamic languages, you still need to document, remember and think about types.
4. Due to the increasing popularity of type inference, a lot of static languages don't have to notate types very often anymore. In static languages with strong type inference, the compiler figures out what the types are from your code so that most of the time, and tells you if you ever do something that violates the type definitions. As far as syntax is concerned, this provides the best of both worlds.
5. OOP and dynamic languages aren't mutually exclusive. PHP now supports classes and even inheritance.

All those surprising similarities aside, there are some practical differences that do influence the development process:

1. Dynamic languages allow for interesting ways of passing data around in the small.
2. Static languages allow you to reduce the amount of testing you have to do by making many kinds of bugs impossible.
3. In that same vein, static languages allow interesting validation and automatic conversion features, like units of measure in F#.
4. Taken to the extreme, static languages allow for code contracts and formal verification, which can document and flat out prevent things like potential divide-by-zeros, infinite loops, null references, invalid list sizes or indices, range errors and other logically invalid state that you might define.
5. Taking that extreme even further, CPU optimizations can be made based on these static constraints, which yields even better performance.

There is also one type of program that could never have been made without static typing: Singularity, an OS without hardware process boundaries. It's written in a small amount of C, some C#, and a dialect of C# called Spec#, which supports code contracts.

Despite being written in a garbage-collected language, multitasking and interprocess communication performance on this OS is in fact better than anything else out there, due to the fact that all the processes run in one memory space, and due to the formal verification optimizations I mentioned above. You couldn't do this without static typing, because in order for programs not to be able to compromise the rest of the system, the communication objects need to be statically verifiable.

Most of the time, though, architectures should look very much the same. Static languages may make programs easier to reason about in many cases because the types are well-defined, but a well-written dynamic language program would also have types that are, at the very least, well-defined in the developers' minds.

I don't think you'll really get anywhere without reworking the way things are done right now.

One example is that during development we only focus on new features and ignore existing bugs and even introduce new bugs.

I am fairly certain that this is a grave mistake. Try to explain that bug fixing becomes more difficult and more expensive the longer it is postponed. I don't think there is any excuse for postponing bug fixes for so long.

All agile methods I know emphasize that the software should be technically ready to ship at the end of each cycle/iteration (or even continuously). That means any bug that you wouldn't want to ship must be fixed before any new features is started.

Try to work with people, and explain your concerns.

Finally, if you cannot get any kind of agreement on such basics, it may be best to move on.

Edit

Based on your amended question: I agree that bug fixing should be handled just like new features. I'd normally have single tasks for "small" bugs (up to a few hours) and stories with subtasks for "big" bugs (multiple days, possible to split into tasks). If your colleagues do not agree, point out that the advantages of agile methods apply to bug fixing just like to new features.

As to wheter to use an agile tracking tool or a bug database: Ideally, the two are integrated. If they are not, then yes, you'll have to track work in both. It's annoying, but I've done it myself, and didn't find it a big problem. You track bugs as usual, and just copy&paste the bug id into the title of a task/story when you schedule a bug to be worked on. The task is just a link to the bugtracker (eays if both are web-based), and all discussion is in the bug db. If you link consistenly, you could probably even run reports across both systems.

Finally, it you believe you cannot change the way development is organized, you'll have to work within these constraints. Things like introducing some agile methods into the bug fixing phase will probably help.

Still, I am convinced that splitting development into a "feature phase" and a "bugfixing phase" is a grave, possibly fatal mistake. It may not be so serious for your company (every situation is different), but if it is, and if your organization is unable to change this, then your organization may be so dysfunctional that you'd be better off elsewhere. But that is your call to make... good luck!

Edit 2

Finally, if company policies dictate "features first, bug fixing later", maybe you can sidestep them, e.g. by redefining bug fixes as new features (the difference is often a matter of opinion anyway). To some extent, you can try to introduce new ideas "from below" that way. You know, "if you can't beat them, join them".