I think your problem is your working definition of "SDE," so some background may help...
When the technology was aquired, "SDBE" was at release 1.3, and had a user base of
roughly twenty sites. ESRI (as they were then known) put a logo on a box, and "SDE"
version 1.4 was released (Database, not DataBase). Development immediately set out
to port the code to Oracle (2.0 & 2.1) and to Sybase, DB2 and Informix (2.1.1). At the
same time the core of the code was taken apart, merged with a development effort known
as the "Projection Engine" and new SDE 3.0 was released. Integration with Arc/Info was s
till limited, but ArcView 3.0 had an SDE accessible API in Avenue, and ArcIMS was able to
connect as well (though not through the nominal AXL editor GUI). The SDE was integrated
more completely with the new ArcGIS and became ArcSDE 8.0. Sybase was out and SQL-
Server was in, with support for the single database model (also available in DB2 & Informix).
Direct Connect libraries were added at 9.0 and the GDB tables re-architected at 10.0.
So, to answer your questions:
1) ArcSDE is a network protocol *and* an application server *and* a DLL library. Even
if you have not configured a service, the Direct Connect DLL thread is fully capable of
accessing an ArcSDE-configured database. ArcSDE technology stopped shipping as a
standalone product at 9.2, but it still remains the method by which versioned geodatabases
are edited by ArcGIS.
2) There are different technology implementations wearing the name "ArcSDE". Personal
and Workgroup ArcSDE *never* run an application server -- they are usually configured
from scratch in an ArcCatalog session. Enterprise ArcSDE can use Enterprise, Standard,
and Express releases of SQL-Server, though the Express version is relatively debilitated
by RAM, CPU and dis limitations. It's far more likely that Enterprise would be joining an
existing instance (and in fact this is recommended over partitioning the geometry from
the rest of the otherwise spatial data).
3) Yes, you may have more than one instance in Express databases, but Express licensing
still limits the storage permitted *across* the databases in an instance ("total" not "each")
I do not recommend splitting data which must be used together across databases. SQL-Server
is very inefficient in mapping users across databases, and rarely needs to be pushed in this
fashion. Conversely, creating DEV, TEST and PRODUCTION databases for use in isolation
is best practice.
4) Esri tries not to dictate how to configure your database. There are limitations in the games
that can be played in mapping logins to users to schemas, but these are due to limits in
identifying geometry columns in queries without them (see a recent post about when you.
must match user to schema). It is generally best practice to use roles to grant privileges
to users, and Esri recommends this practice as well.
Personally, I'd find 4Gb or 10Gb of storage and only a fraction of the CPUs and RAM on my
system far too limiting, but I enjoy loading millions of rows of complex data just for kicks.
- V