I'm building out a schema for a site that will need to store a product's currency. I'm not sure whether I'll be needing to be able to convert from one currency to another, however, I'm presuming that will probably be necessary. My db schema is below. (this is for a mobile app btw). My question is, should I just simplify things by adding an additional column called currency to my item table? Does my design make sense? Thank you.
Edit (based on reply from Victor below): the items have a many-to-many relationship with order table. How about putting the currency id on order table since most likely all items in an order will be in the same currency?
exchange_rates
id
currency_from
currency_to
ex_rate
item_currencies
currency_id
item_id (from items/products table)
currencies
id
code
symbol
The schema looks good but I think that the *item_currencies* table is not necessary.
In your items table you can just add the currency_id column. Keep it together with all the item properties :)
Related
I have a InvoiceAccount field in table. And another field in this table is PackingSlipAXType. If PackingSlipAXType is Sales, InvoiceAccount field value is customer account. If type is PurchReturn, InvoiceAccount field value is vendor account.
When value is customer account, when right click and go to main table i want to go Customer
and
When value is vendor account, when right click and go to main table i want to go vendor.
How can i do this in same field?
There are two primary ways. One is code and the other is using native MorphX and Conditional Table Relations. Code gives you more flexibility, but conditional table relations are simpler and "just work".
Conditional Table Relations
Using conditional table relations. I created a new table and AccountNum would represent a customer or vendor account, and the base enum SalesPurch is used to indicate if it is a Customer Account (Sales) or a Vendor Account (Purch). Similar to your setup.
See conditional table relations - https://learn.microsoft.com/en-us/dynamicsax-2012/developer/conditional-table-relations
See here for more info too.
Custom JumpRef & Lookup
You will likely want both a jumpRef and a lookup to both go to the correct main table and lookup the correct values.. This is code, but you have all the flexibility in the world...but may not need it.
Jumpref - https://community.dynamics.com/365/financeandoperations/b/faisalfareedaxlibrary/posts/ax-2012-how-to-use-jumpref-method
Lookup - https://learn.microsoft.com/en-us/dynamicsax-2012/developer/how-to-add-a-lookup-form-to-a-control
Jumpref example at \Data Dictionary\Tables\TmpCostAllocationBase_RU\Methods\jumpRefAgreement
Lookup example at \Data Dictionary\Tables\TmpCostAllocationBase_RU\Methods\lookupAgreement
I'm struggling to decide what database schema to use. One large table, or many small (though more difficult to manage).
I have 10 templates each with their own text fields. I am trying to store the text for the templates in a database and then when the web page is called I will show the correct text in the html template. Because a mixture of these templates are to be in a sequence of screens where you can navigate backwards or forwards, I need to be able to sequence them, I can only think of adding a page_number column. I also would like to re-order them and delete them as necessary using the page_number column.
I was planning to do all this in a web application without the need for a standard folder/web page structure, like a small CMS system.
option 1,
I can create one large table with many columns, lot's of which will be empty, over half with each row. Is this bad?
option 2,
I could create many tables using only the relevant template columns required.
The problem I see with this, is the headache of repopulating a column in each table when I delete a row, because I need to re-sequence a column that represents page numbers. Which I reduce if I use one large table.
I've thought of moving page numbers into another table called page_order but I cannot think of a way to maintain an effective relationship between the other tables if I make changes.
I'm yet to figure out how to re-sequence a column in a database when a row is deleted. Surely this is a common problem!?
Thanks for taking the time to help!
Have one table that contains one row per template. It might look like:
id (INT, auto-increment)
page_order (INT, unique key here, so pages cannot have the same number)
field1 (STRING, name of the text field)
value1 (STRING, contents of the text field)
field2
value2
Then you have to decide the maximum fields that any page can have (N) and keep adding field/value columns up to N.
The advantage of this is you have one table that isn't sparsely populated (as long as the templates have about the same number of fields, even if the names of those fields are different).
If you want to make an improvement to his (maybe not necessary for a small amount of data) you could change field to an INT id and connect it to a lookup table that contains (field_id, field_name).
Im using Asp.net (VB.net), in my Database :
have One table called (Trade), the same rows of this table are used from 3 different users, These users can make different updates on this table, they should see the basic informations of the table (I mean by the Basic, before the table (trade) has been updated)
The problem is here when the first user wants to modify the table's rows, the second and third user cannot see the basic information any more, and if they decide to change or update some data, the first will lose his updated rows..
The data will be overwritten every time the users make updates on the table.
What I want, is to know if there is a way to do like a copy, or an image of the table for the 3 users, and every user can update normally, without creating the same Table with the same rows 3 times??!
Update
My table structure is: Trade(trName, Carrier, POl, POD, Vgp, Qgp) There is no primary key..
Thank you..
Solution to your problem could be two copies of the original table. Show the original table always to the user as the initial data. And in second table keep the updated data always. Now the trick comes here to maintain the log, for that you have to maintain the log table, this table will have all the fields of original table along with one additional column "UserId", this will have the ID of user who has changed the value. Now each time before updating the data, copy it in the log table. If this suits your need then post the fields of your table then we can workout on the table structures.
I have a table in the database that store 4 category and the structure of the table is ID (GUID), description. I load the category into a dropdown list (asp.net webform) to allow people to select a category and based on what they selected. I'll then display info associated with their selection and hide the others.
Currently, i do a "select case" based on the GUID that i hard coded in code behind to display the associated info. Is there a better way to do this without hard code in GUID on the code behind?
What is the Data that's associated with the Guid/Description...
The data you've hardcoded sound's like a candidate for being added to the database itself.
If it's one piece of information per Category/Guid, then consider extending your Database Table to store that info to.
If it's multiple piece of information per Category/Guid, then consider creating a new Table With a CategoryID on it, and a foreign key relationship between your Category Table and your ExtraInfo table
You could query the database for the GUIDs when the app starts and cache them in a static Dictionary.
you could store the GUID in your web-config and load it at run time. then, you can easily replace that GUID with another w/o having to recompile.
You should have a Categories table and a Posts table (or whatever it is that you will tag with your categories). In the Posts table you have a column for the CategoryID (assuming each post can only belong to one category), so that you only have the category name in one place (normalize your data).
When you render the dropdownlist, you select the GUID:s from the database. No hard coding, and if you add another category (or remove one) the dropdownlist will automatically reflect the available categories.
If you bind the dropdown list to the Category row or a Tuple that contains the category name and the value you can load the Guid in your codebehind using the SelectedValue property. You will then set the DataTextField and DataValueField on the Dropdownlist.
I have a table that contains three columns.
"UserId" type-nvarchar
"PostAuthorId" type-nvarchar
"Post" type-text
This table will contain "wall" posts like in facebook for each user's page. I am going to use a gridview on each user's page to display the posts. The issue is I want to display them with the latest(most current) post being first and the earliest post being last.
I have never used autoincrement before and I am not sure if that is the answer. If it is, I do not know how to use it. I thought about adding a date posted column and then ordering by date.
If I end up using the date column, I could also display the date on the post. Is there a way to convert the date to a readable format?
What is the best way of implementing this type of ordering?
If you use AutoIcrement the first record will start with 1 and each record will increment from there. (default setting)
If you want to sort them by newest first do an ORDER BY ID DESC
I would suggest making a column called wallPostID then setting that to AutoIncrement and also your Primary Key
Date Formating:
If you are displaying this data in a gridView
Go to Edit Columns on your grid view
CLick on the Date field under "Selected Fields" on the bottom left
Under "BoundField properties" on the right Go to Data -> DataFormatString
{0:d} will display as 1/1/2010
This site has more info in string formatting
http://msdn.microsoft.com/en-us/library/fht0f5be.aspx
A datetime column would definitely work for something like this. Assuming you are using MS-SQL, you can also attach a default value to the column using a built-in function like GETDATE(). That way, you only have to input the data that matters and the database will take care of adding the datetime column.
For converting a datetime to a readable format try:
DateTime postDate;
string value = postDate.ToShortDateString();
You should always use an ID field that auto increments. Can also be used as your PK
I would suggest the DateTime field rather than the autoincrement simply because it will not only serve as an effective Sort field, it also preserves information that you may well want to display. If you want the most recent first you'll sort using the Date and a "DESC" modifier:
Select ... Order By [Date] DESC;
When you retrieve the data, you can retrieve it as a DateTime and modify it using C#. You can use "ToShortDateString()" as suggested by mdresser if you just wish to show the date or ToString("...") if you wish to show the time as well. You can also use SQL to convert it into a string before retrieving it:
convert(Varchar(10), #mydatetime, 101)
If you look in MSDN you'll see the various conversion codes (101 is the code used above) that can be used to translate the date in various ways.
UPDATE: You may want to use an autoincrementing field for your application for reasons other than your expressed need to sort wall entries. They are easy to use - just mark the field as an Identity if using SQL Server (other DBs are similar). As far as using them in your program, just think of the field as an Int field that you never have to set.
Now, why would you use a auto-incrementing field? Perhaps the most straightforward reason is so that they give you have an easy way to identify each record. For example, if you permit people to alter or delete their wall entries, the auto-incrementing field is ideal as it gives you a way to easily look up each record (each record will be assigned its own, unique value). You might put an "x" next to the record like StackOverflow does and make it a call back with the UID (auto-increment) value. Note that you should set up your primary key on the UID field if you'll be doing this.
Now, if you find them useful for this reason then you could also sort by the UID. I would still store the date so that you can provide Date and Time feedback as to when an entry was made on the wall but this would no longer be your indexed or sorted field.