Is there a way to pull out the state abbreviation from an address? I am using an event calendar extension for Joomla for my site and it currently only stores the city and county separately in the database but it does give the address all together, ie. 123 Main St., Townsville, ID 55555. Is there a way to grab the two letters of the state and spit that out instead? Even if there might be a way to grab all of the two letter occurrences and then compare those to a list of state abbreviations to validate.
Thanks
Jason
The problem with extracting the information the way you're asking to is that some people might enter the entire State name, some might abbreviate the state, some might misspell the state... etc.
You can't count on people to give you the right data... it's just a fact of programming.
You could extend the database and form to include the State separately... going further, you could use a predetermined Ajax AutoComplete extension or a Dropdown List in order to ensure the user is selecting the correct State.
In my apps, I enter all of the US States and all of the Canadian Provinces in a Region table. Then in the Person table, I have an int State. That way I can join the person's state to the region table and save valuable db space. But that's just me.
dbo.Person
| ID | Name | Address | Zip | StateID | etc... |
dbo.Region
| ID | ParentID | Name |
Related
I am not sure if there is another option for this so if someone could give me some advice, it would be greatly appreciated!! Keep in mind, I am a new developper so don't be too harsh with the answers.
So basically I'm developing a web application and I want to give the Admin the possibility to change the email address that will receive a copy of all sent emails (it makes sense in the case of the app). So I got this field where I temporarily have an email address, but once the client gets the app, I want them to be able to modify this email address whenever they want to.
My question is: Should I create a table in my database to store only this email address and thus be able to send a request to modify it when the Admin decides to or is there another way to do it?
Edit: Tell me if I should remove the tags or if there are any better tags for this topic!
There is often a "Admin Settings" table in many applications that allows things like this in a key-value pair sort of model.
|Setting |Value |
++++++++++++
| ccEmail |admin#yourapp.com
| othersetting| 3 |
I am working on an application using the Yii framework, so its MVC-style. I have a record type "person", which contains information about membership. Members come in two types: adults & kids. With the kids, SOME of them we know their ages and they are divided into age groups. The age groups have names (e.g. "8 & Under".) So as an example, John Smith & Jane Smith have two kids Jimmy Smith and Janey Smith. Janey wants to do a soccer program, so we need to know her age and put her in an age group. Jimmy is doing arts & crafts so we don't need to know his age because his program isn't divided by age. And we don't ask for the ages of the adults.
So the question: I have a few choices about how I store this. I could:
put an int agegroup field in the person table, and define the values as CONST values when I define the model for people (and probably have a special value for "undefined" - for the adults. Then I need to write a little code to translate the const value to descriptive labels.
put an agegroup field in the person table as above, but also add another table in the database with the reference data. Enforce referential integrity to this new table. This raises another question - should I create a dummy record in the reference table for cases where I don't know/care about the agegroup, or should I allow null values in the people table agegroup field?
others?
I know I can make either of these work. But I would welcome advice on which approach is preferred and why!
For the possibility of future expansion (you may want to create, delete, and modify age groups) I would recommend having an age group table consisting of a beginning age, an upper limit age, and a description. You can leave the beginning age as null to signify a 'up to n'/'n and lower' group, or vice versa with the upper limit. The primary key would consist of the beginning and upper age together (composite key.)
Then, in your 'activities' table, you would need to enforce a reference to the age group table (even if just to a 'null/null' or 'all ages' record.) This way you can create activities for age groups -- 8 and under soccer, 12 to 14 soccer, all ages crafts, 18 and older art, and so on.
I need to build an application where there are generic entities (let's say articles, pages, nodes) where the user can add custom fields.
I've seen the approach that the most popular php CMS (wp, drupal) use to get this goal; They all have the base table with the minimum fields (e.g. title and body), and then delegates all the other fields to other tables, for example:
table node
id | title | body
table field_foo
node_id | field_type | field_value
table field_bar
node_id | field_type | field_value
// and so on
This, in a full mvc environment is pretty logic; The field controller handle every field separately.
But talking about performance, loading a single node will require many queryes - or many joins.
I've taken a different approach (even becose my app does not provides any base field): for every field i add a new column on the base table that will store a raw value, then a table for every field that need it (multiple fields for example, or reference to other entities) and an relation table with just indexes entity_id | field_id (that table actually do other kind of jobs, as keep track of versioningn and kind of relations between entities)
So with a single query i get all the raw data from an entity, then the field controller knows (when required) how and where to load the real values of that fields.
The column's type in the data table (table_entity_data) is the best guess for the field data: for text is text, for decimal is decimal; only for multiple fields (that have theyre value outside that table) is array (and the real data_type is in the _field_foo_value.entity_value_ column)
Assuming that the entity structure wont change often, i tryed to normalize the structure..
Given that other big projects handle this in a very different way I have come to doubt about my implementation, and wondering what kind of problem will happen with my hibryd structure:
table entity
id
table entity_data
entity_id | field_foo_rav_value | field_bar_raw_value
table relations
entity_id | entity_field_id | field_id_value
table field_foo_value
field_value_id | entity_value
// lets say field_bar is a single text field, there no will be another table:
// entity_data.field_bar_raw_value contains the real value
Any suggestion?
p.s: i know this question is kindly generic, feel free to flag for closing if not appropriate.
Looks like you're re-inventing EAV
http://www.google.com/search?q=entity+attribute+value+antipattern
Downsides are that you're throwing away all the type safety and structure that a relational database can provide.
In an ideal world, you probably want one of:
Allow the building of a proper table
Use a non-relational database
We currently have a system that have contacts in it. It will be mapped to the contact entity in Dynamics. Each of the contacts have an address history (Yes, some of them moved in the last 20 years).
We are soon to import the old system in Dynamics, and I am wondering how can I import a contact address history. Let assume I have user 'John' :
| Name | Address | LivedThereFrom | LivedThereTo |
-----------------------------------------------------
| John | 123 X road | 2005 | 2008 |
| John | 123 Y road | 2008 | 2010 |
| John | 123 Z road | 2010 | | ==> Current address
So I will import 'John', then (with audit activated on addresses) import his address from 2005 to 2008, then update it's adresse to '123 Y road', then finally update it to '123 Z road' to have the full history available in Audit.
The problem is the following : How can I 'tag' those adresse from 2005 to 2008, 2008 to 2010 and then 'current'... I thought of using the 'created_on' field in the Audit table to help me, but there seems to be no way to modify that data (except going directly in the database and lose Microsoft's support on the product).
Thanks
If the client insists on through the product, then then another option is to import the addresses multiple times.
Setup
a) Turn on Auditing for the entity.
b) Add a new field to store the Date in which the Address was first used (Address Commencement Date)
Import
a) Import all Customer's oldest addresses first, set the Address Commenecement Date to the LivedThereFrom date
b) Export the addresses and make it available for re-importing.
c) Update the valyues in the spreadsheets based on the next available LivedThereFrom for that Customer. Hint: Convert the exported spreadsheet to XLSX first. Use formulas to work out which ones to replace.(e.g. VLOOKUP) If really large spreadsheet then may need to split to enable re-importing under 5MB limit. Could use ROW_NUMBER function in SQL to get a list of next addresses to update from your source system.
d) Continue doing c) until all records are loaded
In the Audit history you will see the the date which the new Address became active with the Address Commencement Date.
If they don't mind the direct database approach I'd go straight for the audit tables
Good luck.
One way that doesn't involve changing the way Dynamics handles contact addresses or doing any unsupported stuff is to make a custom entity the job of which is to store all of your contact's address history. It could contain the address, the dates between which that contact lived there, and (importantly) an N:1 or N:N relationship between your new address entity (say new_Address) and the Contact entity that links the two together.
A drawback is once this is done, you probably would have to introduce some business logic to sync the contact's address records to this new entity, which is certainly possible within Dynamics, and perhaps at some level, unavoidable.
One of the most common problems I run into when creating any information system is the fact that people go by so many different names. Someone named "Bill Smith" may go by "Will Smith","William Smith", "Smith, Will", etc... If say, I wanted to write an application to link blog posts to authors, I would have to account for all those names.
My question is: What approaches do you take to keep consistent data throughout your application. How do you structure your database so that you can refer to a single identifier to locate all those names? What UI approaches do you take make sure that people enter in names in a consistent manner?
As long as you have a unique id for each user (which is not their name) you can have a table that maps name variations to a unique id, and then associate each post with that unique ID.
(Table mapping names to UIDs)
Name UID
Robert S 123456
Bob S 123456
Bert S 123456
Darren 987654
(Table with post information, including author's UID)
Title Author ...
Post 1 123456
Post 2 123456
Post 3 987654
(Table with author information)
UID Preferred Name Webpage ...
123456 Robert Smith http://www.robert.com
987654 Darren Jones http://www.jones.com
It's probably a good idea to accept only one name from your user, and allow them a "nickname" or a "public name". That gives them the freedom to have a legal name, perhaps for mailing or billing, and a public-viewable name for interaction on your site.
Beyond that, I don't think I would allow my users to have multiple names, unless my system required it. If I did, I'd split it up into two tables:
Users:
userid (ex: 1821)
UserNames:
userid (ex: 1821)
firstName (ex: Jonathan)
lastName (ex: Sampson)
In addition, you could add a field in the usernames table called 'isPrimary'. This would be a boolean value that will tell you which name to treat as the primary name for the user. This is similar to how wikipedia store a history of data/changes. They keep all, but mark which is "active", or in your case "primary".
It sounds to me like you are trying to use their name as a primary key or UID. This is the wrong way to go. You should have a seperate UID as the primary key, then the name can be whatever you want, and you can even have a list of alternate names.
The real problem happens when you have multiple applications, and each one has their own schema for user information. The billing system might have "Will Smith"; the payroll system might have "William Smith"; the claims system might have "Willie X. Smith". All are really the same person. What do you do? It's a huge issue for stovepipe, legacy apps.
I agree with the first 3 posts on how to structure your schema.
In regards to the UI I would allow a field for the persons legal first,middle and lastname which should change very rarely.
Then allow nickname(s) depending on your application requirements.
Having their full legal name can come in handy for billing/financial/HR situations too.
You could always make a AKA table, where you could have the prefer name to AKA name. So if someone uses the name Bill, you can always replace it with William.
I have never personally used this concept for names, but I do support a project that does something similar with Movie Titles, which can varied for different countries.