But what about the "Model" file that is offline ? Someone can get and restore to another PC.
I read somewhere about encrupting the database.
Is this true and how can be done.Can this be a help in my situation ?
One approach is to NOT give users direct access to the machine where database system is running.
Have a middle tier server application(eg: tomcat) hiding your database from end users. Users may connect to middle tier server and invoke services. You may implement authentication using some standard framework within middle tier server application.
If I understood your question correctly, you're worried about several, different things. As Mycroft said, the topic is way too large to discuss extensively in a post. However, few things I'd like to point out:
Now the problem is this : The field Item_id on the sell_item table can be the id for an Article or a Service. So I need to create a double relationship for this field one with Article table an one with Service table.
Is this possible ?
If not , or if I'm wrong how can I solve this situation ?
ok , but as I can see you have merged my 2 tables. Me to I have thinked this , but the problem is that in my post I have included only some of the fields from 2 tables. In reality these tables have 15 and 13 fileds , and do you think is a good choice to have a table with 28 fields where for each record only 15 or 13 fields will have the data and others are just unnecessary ?
In my opinion it's ok to have merge the tables and have nullable columns as long as the data is suitable concerning the table purpose. However, without seeing the whole model, it's impossible to say if this is feasible solution in your case.
As a rule of thumb one column stores data only for one purpose. What I mean is that even though you can do a dual reference, it's not advisable.
Another approach could be to use a whole separate table for the links. Consider the following
other possible fields describing a single selling action
Again this should be verified against the whole model and I must admit, I would put all the effort in modeling the sell able products properly instead of thinking how to simultaneously reference two separate tables. That would keep the model simple and clear
In the rare time when I have had to do this I live without the FK, it is not possible to have the FK to both child tables.
I suspect your 28 field count on the merged table is not valid, there should be some cross over (description in both tables). I would also have no compunction about merging the tables and having some nullable fields as Mika suggested.
Never underestimate the power of human stupidity
This is a typical supertype-subtype situation. I would consider ITEM as a supertype and ARTCLE and SERVICE as subtypes.
Common attributes of ARTICLE and SERVICE should go to ITEM and there should be identifying relationship from ARTICLE and SERVICE to ITEM.
I dont know how to attach an ER Diagram hence pasting a DDL for the schema.