Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>When evaluating the Singleton pattern, you have to ask "What's the alternative? Would the same problems happen if I didn't use the Singleton pattern?"</p> <p>Most systems have some need for <i>Big Global Objects</i>. These are items which are large and expensive (eg Database Connection Managers), or hold pervasive state information (for example, locking information). </p> <p>The alternative to a Singleton is to have this Big Global Object created on startup, and passed as a parameter to all of the classes or methods that need access to this object.</p> <p>Would the same problems happen in the non-singleton case? Let's examine them one by one:</p> <ul> <li><p><b>Memory Management</b>: The Big Global Object would exist when the application was started, and the object will exist until shutdown. As there is only one object, it will take up exactly the same amount of memory as the singleton case. Memory usage is not an issue. <i>(@MadKeithV: Order of destruction at shutdown is a different issue).</i></p></li> <li><p><b>Multithreading and bottlenecks</b>: All of the threads would need to access the same object, whether they were passed this object as a parameter or whether they called <i>MyBigGlobalObject.GetInstance()</i>. So Singleton or not, you would still have the same synchronisation issues, (which fortunately have standard solutions). This isn't an issue either.</p></li> <li><p><b>Unit testing</b>: If you aren't using the Singleton pattern, then you can create the Big Global Object at the start of each test, and the garbage collector will take it away when the test completes. Each test will start with a new, clean environment that's unnaffected by the previous test. Alternatively, in the Singleton case, the one object lives through ALL of the tests, and can easily become "contaminated". So yes, the Singleton pattern really <i>bites</i> when it comes to unit testing.</p></li> </ul> <p>My preference: because of the unit testing issue alone, I tend to avoid the Singleton pattern. If it's one of the few environments where I don't have unit testing (for example, the user interface layer) then I <i>might</i> use Singletons, otherwise I avoid them.</p>
    singulars
    1. This table or related slice is empty.
    1. POProblems with Singleton Pattern
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USAndrew Shepherd
    1. USAndrew Shepherd
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThe comment about memory management is wrong in C++, in my opinion. The "singleton" as a member object of the application object (as defined by the framework), for example, has a *well-defined* time of destruction. Any singleton implementation based on a "static" somewhere is prone to the static initialization / destruction order fiasco. I've seen some really ugly hacks to get around accesses to singletons from the destructors of other singletons.
      singulars
      1. PO
      1. USJoris Timmermans
    2. COThis is pretty much what I say in these two blog posts: "Uncontrolled coupling" - http://www.lenholgate.com/archives/000259.html and "Singletons and testing" - http://www.lenholgate.com/archives/000357.html. Use the "good half" of the singleton design pattern (only one instance) without the bad half (accessible from everywhere) and many of the singleton problems go away. Once you get to here you can pretty much move away from the "good half" as well as much of the time things are singletons just because of the "accessible from everywhere" thing, i.e. they are really just global objects...
      singulars
      1. PO
      1. USLen Holgate
    3. COWhy is "only one instance" the "good half"? Why would you ever want that? That seems to me to be an even worse problem than global accessibility. Globals are *sometimes* useful. But by preventing creation of more than one instance, you're crippling your code base. You don't know how the class is going to be used in the future, and yet you happily nail it down and prevent all but the most trivial usages of it.
      singulars
      1. PO
      1. USjalf
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload