I'm writing an application that reads data from a relational database, let's the user change the data, and writes it back.
I am unsure how to deal with the primary keys since I do not want to show them in the user interface output. What are good practices to hold the primary keys invisible for the user but so that they can easily be retrieved after the changes in the gui are made?
I use C#, Windows Forms and sqlite, if needed.
EDIT: Example: I have a text input that contains the wage of a employee. Can I save the the primary key of that employee bound to that text input, so that changes made by the user can be written back easily?
If you're using an ORM you have the PK as a property of the object. If you're using SQL queries directly you can hold PK in an internal variable in your form class.
Related
I know that each time a user registers in my ASP.NET MVC application the ApplicationUser class is used to create the new record and put it in the database.
I was wondering if it's okay to add properties to that class for example I want the model to have a column in the database for DateOfBirth. Then use that class(model) directly in my application when I have to do some business logic things, database queries and similar stuff. Or is it more correct to create a new table in the database called let's say ApplicationAccounts, that saves the general info about the account. Each ApplicationAccount will be associated with a ApplicationUser(1 to 1 relation) and be somewhat of a buffer in the communication with the real accounts. Does that make sense?
I would go with the second option : create your own table, link them up in a one to one relationship using the UserID as a unique foreign key and then go from there.
One note here, it is perfectly normal for the model you need for the views to be different from the database model, this is because your db model can hold a lot of data that your view doesn't actually need. You might want to consider having separate models and use something like Automapper for a quick translation from one to another.
I want to build an online form builder much like wufoo that allows the users to create and publish their own web forms. Each submission should be saved to a data base where the user can later retrieve the submissions.
As these forms will be dynamic, ie. the user has complete control over the amount and type of form fields I am trying to think of a solid database design to store this information.
I would have one table fieldtype which contains every type of field available to the users, ie. textfield, emailfield etc.
One baseform table which will hold each forms id, url etc.
I would then have a table formfields which would contain ref to the baseform and to fieldtype, this table could also include custom validation to be done on each field.
Is this design good as a base structure? I imagine it will be easy to add new types of fields to the application however I don't know what the potential downsides are as I am far from a sql expert.
store user defined data in SQL
I think you are looking for the Entity–attribute–value database model in which:
The basic idea is to store attributes, and their corresponding values,
as rows in a single table.
Typically the table has at least three columns: entity, attribute, and
value. Though if there is only a single relevant entity, e.g. a table
for application configuration or option settings, the entity column
can be excluded.
See this pages as a start:
Using Database Metadata and its Semantics to Generate Automatic and Dynamic Web Entry Forms (pdf)
Planning and Implementing a Metadata-Driven Digital Repository (pdf)
I retagged your question with entity-attribute-value tag, in which you can browse a lot of threads that relate to your case.
As Mahmoud Gamal writes, The model you describe is "Entity/Attribute/Value"; as Borys writes, there are many known problems with this model.
As an alternative, you might consider storing the form entries in a "document" - e.g. XML or JSON - within a relational model.
For instance, you might have a table along the lines of:
FORM_SUBMISSION
--------------------
Submission_ID (pk)
Client_ID (fk to clients table)
Submission_date
SubmissionDocument
I'm using "client" to represent the users who create the form; to retrieve all submissions for a given client, you use a where clause on client_id.
This model makes it harder to run SQL queries against the form submission (though that becomes hard with EAV too when going beyond very simple queries), but it dramatically simplifies the persistence solution.
I am new to VSTO, and am developing an addon to Outlook that will allow the end users to track relationships between contacts. The relationships are stored in a separate SQL database, and I put the ID of the SQL data row in a custom property attached to the Outlook contact. Unfortunately, if the user ever views the "All Fields" pane, this ID is visible under "User-defined fields for this item". Is there any way to prevent the user from being able to see (and more importantly edit) these properties?
I don't believe there's any way to "attach" data to OL contacts that can't be seen by the user.
On the other hand, you could have a field in you DB that tracks the Contact ID (I forget the exact field name offhand, but I know each contact has a unique key value associated with it) and then use THAT when getting to the data in your SQL DB.
The only problem with that approach is that outlook has a habit of resetting that PK value when you do certain things (like move a contact from one folder to another, Outlook treats that as a DELETE/ADD, so the PK for the contact will change).
I seem to recall using a hybrid approach at one point that did BOTH (stored the PK of the contact in SQL and a custom field in the Contact stored a SQL ID) and then just keeping them synched. But as I recall, it was a bit of a pain.
alternately, if the user moved a contact, YOU could also treat it as a DELETE/ADD and update your SQL as applicable.
I have an existing nhibernate web application and I'm about to add a configuration table that will contain all system wide configuration options. This table will always contain one and only one row. Each column will contain one configuration property. I plan on having a domain object that will have a matching property for each column in the table. The users will be able to modify the values for each property in an admin screen. I plan on populating the table with one row during installation, setting initial values for each configuration option. My questions are as follows:
1) I only want the system to update the existing row, and want to block any deletes or inserts on the table. I can, of course, enforce this by not creating application tier functions that do deletes or updates, but I wondered if NHibernate had some built in mapping or configuration options to help. I'd prefer to not have to do this at the database level since we are writing a database agnostic application, and so far, have not had to write any database platform specific code or scripts.
2) Would the mapping be different for this class than my other "normal" classes?
Answer to 1) NHibernate does not have any "configuration" that will enable to block "inserts" and "deletes" only. You can do work arounds e.g. Write an your own PreDeleteEventListener and PreInsertEventListener and stop updates and inserts if the entity is your configuration entity.
However I would advise you do to enforce this configuration via the application i.e. the configuration repository should only expose an Update" function and no more.
Answer to 2) I am assuming that this table does not have a primary key (as it is the only row in the table). As far as Im aware, NHibernate cannot work with entities that do not have primary keys. You may have to add a primary key just to get it to work for NHibernate
Question: I'm planning the database for one of my programs at the moment.
I intend to use ASP.NET MVC for the user backend, the database being on Linux and/or on Windows.
Now, even if I would only make it for windows, I had to take into account, that different customers use different database systems. Now, I figured I use nHibernate, then I can put everything in the code, and it works on all mayor databases, such as Oracle/Sybase/MS/PostGre/MySQL/Firebird.
My probem now is GUIDs. SQL Server uses GUIDs, while the rest uses integer auto-increment as primary keys. While auto-increment is better in theory, it creates problems keeping multiple databases in sync, or problems manually changing things, which requires CSV import/export...
Now, because of the inherent problems with autoid in practise, I like the GUID system better. And since a guid is a 36-character string, I could use varchar(36) as a primary-key, but a varchar as GUID, might just not be an ideal solution...
How would you solve this problem/what do you use as primary-key ?
Or how do you evade the auto-increment problems, say insert a csv file without changing the autoid...
A Guid key using the guid.comb generator key is usable in any database, even if it doesn't have Guid as a native type.
You could also consider generating a primary key which is a combination of auto-increment (i.e. setting up a sequence) and an unique identifier of the machine it was generated on, maybe using the MAC address.
See this for a discussion.
This way you have a locally unique (thanks to the sequence) ID which is also globally unique (thanks to the MAC address part).
I know, I know, you can spoof a MAC address but it's up to you to decide if this is really a risk in your domain. Also, the ability to spoof it could be handy when you test your code.
Please explain better what happens when a new customer DB is born. Will it be registered on the Server? If yes, you can assign a DB-id on the server, and use it in lieu of the MAC address, just assign a number to each new DB and use it along with the sequence.
Basically, if you want an "unique DB instance ID" to avoid "table id" collisions, you have only two choices:
1) Server assigns the DB ID whenever a new DB is added
2) Client autogenerate a unique ID, and this usually needs using the MAC address, either "raw" or processed somehow.
I honestly can't see alternatives given your current description of your problem.
Oracle and PostgreSQL support GUIDs as well, there is no need so use sequences there (and of course Diego is right: if you use your own algorithm to create GUIDs you can always store use a varchar column with your own generated GUID)
Note that it's spelled PostgreSQL, never PostGre
I have never had any trouble using Guids. We used Guid.Comb in a system with many records (millions) and had no trouble because of the Guids themselves. The selling point for me is that I can generate the Ids before i persist something to the database. Even on the client. Which is very helpful in CQRS scenarios.
The only thing that I think you should also consider is human readability. It's hard to look at the database and match records in a lets say master/detail scenario.
And a note on Firebird... Uuid is written as an octet. And most clients that I've used to manage the database can't represent those in a decent format. So it's usually just displayed as a couple of characters (probably by just decoding a byte array as a string). I don't know about other providers though. SQLServer Management Studio for example shows them just fine.