Spliting a database and Read Only Users

[djb]

Hi,

I have been importing a number of tables and I am building a database about 30-40mb in size with 36,000 records. There will be around 8 potential Users, 7 of which will only have read only access via network permissions to the folder where the mdb will reside. They will only hit the database for some simple select queries (possibly through Excel) and also through some Access reports. Of course it is unlikely that 2-4 will be in it at any one time.

A) Do I need to split the database into a Front End/Back End structure especially since all but one of the Users is Read Only. In otherwords is the concurrent Users and splitting the database more an issue when editing is done by multiple Users rather than just viewing the data?

B) Since access to the database will be done via Excel links or some simple reports via an Access mdb on each Users machines that are linked to my home mdb, am I not in effect spliting the database?

Thanks for the design concepts help.

djb

 

[Scott McDaniel]

--
Scott McDaniel
CS Computer Software
Visual Basic - Access - Sql Server - ASP

Hi,

I have been importing a number of tables and I am building a database

about 30-40mb in size with 36,000 records. There will be around 8 potential
Users, 7 of which will only have read only access via network permissions to
the folder where the mdb will reside. They will only hit the database for
some simple select queries (possibly through Excel) and also through some
Access reports. Of course it is unlikely that 2-4 will be in it at any one
time.

A) Do I need to split the database into a Front End/Back End structure

especially since all but one of the Users is Read Only. In otherwords is
the concurrent Users and splitting the database more an issue when editing
is done by multiple Users rather than just viewing the data?

Yes. There are MANY reasons to split the database; I can't think of a single
good reason to not split it.

B) Since access to the database will be done via Excel links or some

simple reports via an Access mdb on each Users machines that are linked to
my home mdb, am I not in effect spliting the database?

If your forms/reports AND data are in the same container, then you haven't
split your database and you WILL experience corruption. If your data tables
are not in the same container as your interface, then you're okay.

 

[TC]

From your figures, each record must be ~1 Kb long. Those are fairly big
records. Are you sure your tables are properly normalized?

TC

Hi,

I have been importing a number of tables and I am building a database

about 30-40mb in size with 36,000 records. There will be around 8 potential
Users, 7 of which will only have read only access via network permissions to
the folder where the mdb will reside. They will only hit the database for
some simple select queries (possibly through Excel) and also through some
Access reports. Of course it is unlikely that 2-4 will be in it at any one
time.

A) Do I need to split the database into a Front End/Back End structure

especially since all but one of the Users is Read Only. In otherwords is
the concurrent Users and splitting the database more an issue when editing
is done by multiple Users rather than just viewing the data?

B) Since access to the database will be done via Excel links or some

simple reports via an Access mdb on each Users machines that are linked to
my home mdb, am I not in effect spliting the database?

 

[djb]

Scott

Doesn't performance degrade when splitting the database

Dave

 

[djb]

TC

I am sure it is normalized. Very little in the way of data redundancy. There are a lot of tables and fields and look up codes. Nearly a hundred tables in fact

Dave

 

[TC]

Hi djb

Redundancy is not the only thing to look out for. For example, repeating
fields (WEEK_1, WEEK_2 ... WEEK_50) are not "redundant", but they sure
aren't normalized.

Cheers,
TC

TC,

I am sure it is normalized. Very little in the way of data redundancy.

There are a lot of tables and fields and look up codes. Nearly a hundred
tables in fact.