I've tried looking around the internet for an answer, but because I don't understand databases very well I'm having trouble phrasing my question to work as a Google search.
I apologize if this has been answered somewhere, but I can't seem to find it. A link to something that could answer this would be greatly appreciated.
I am trying to set up tables in my database. I have a Software table that contains many fields, including a field called "Compatible with."
"Compatible with" is used to store the operating systems this software is compatible with (i.e. Windows XP, Windows 7, etc.). Simple enough.
With other fields that have a set number of responses (like dropdownslists), I have normalized the database with separate tables and foreign keys. My guess is that it would be "good practice" to do this as well for the "Compatible with" field, but I'm not really sure how I should set up the normalized table.
I found something here http://forums.asp.net/t/1675666.aspx/1 that may be the right direction to go, so I thought of making my table like this:
Column Name Data Type
CompatibleWithId int
Windows XP bit
Windows 7 bit
...want to be able to add more later...
The problem I ran into is that in the future I will need to add to the list of options in the "Compatible with" field. Is there a way in C# code (I am using MVC 2 and Entity Framework 4.3.1 I believe) to add a column to a table like the one above? Or is there a completely different way I should be setting this up?
According to my understanding of your software requirement (please correct me if i am wrong), here is how I will have the database schema
table1: software (id, name, blah, blah)
table2: operating_sys (id, os_name, version)
table3: compatibility (software_id, os_id)
Relations:
Software to compatibility --> one to Many
So compatibility table will have multiple rows for each software. Now in future if you have more Operating systems, or versions you can add them in the operating_sys table, and add a corresponding entry in compatibility table.
Is that what you were looking for?
Related
I have a situation as described in the ExtbaseFluid book:
I would like to store information in the intermediate table which is not recommended at all.
Here is a cite from the warning box of the above linked book chapter:
Do not store data in the Intermediate Table that concern the Domain. Though TYPO3 supports this (especially in combination with Inline Relational Record Editing (IRRE) but this is always a sign that further improvements can be made to your Domain Model. Intermediate Tables are and should always be tools for storing relationships and nothing else.
Let’s say you want to store a CD with its containing music tracks: CD -- m:n (Intermediate Table) -- Song. The track number may be stored in a field of the Intermediate Table. However, the track should be stored as a separate domain object, and the connection be realized as CD -- 1:n -- Track -- n:1 -- Song.
So I want not to do what is not recommended. But thinking about the workflow for the editor that results of the recommended solution rises a few question for me.
To stay with this example I would need the following tables:
tx_extname_domain_model_cd
tx_extname_domain_model_cd_track_mm
tx_extname_domain_model_track (which holds the track number)
tx_extname_domain_model_track_song_mm
tx_extname_domain_model_song
From what I know this would end in the situation that the editor would need to create following records:
one record for the cd
one record for the song
now the editor can create one record for the track.
There the track number is added.
Furthermore the cd record needs to be assigned as well as the song.
So here are my questions:
I guess this workflow cannot be improved with some (to me unknown) TCA setup?
An editor cannot directly reach the song when the cd record is opened?
Instead first she / he has to open the track record and can from there navigate to the song?
Is it really that bad to store data in the intermediate table? The TYPO3 table sys_file_reference does the same!? But I wonder how those data could be shown (because IRRE is not possible because it shall only be used for 1:n relations (source).
The question you have to ask yourself is: Do I want to do coding by the book, or do I want to create a pragmatic approach to solve a customer's problem?
In this specific case the additional problem is, that the people who originally invented Extbase had a quite sophisticated and academic approach, but when it comes to a pragmatic use and performance, they were blocked by their own rules and stuck with coding by the book.
Especially this example and the warning message shows a way of thinking that was one of the reasons, why I never actually used Extbase but went for Core-API methods to create performant and pragmatic queries to get the desired result sets. Now that we've got Doctrine under the hood, this works like a charm even with quite exotic DB flavors.
Of course intermediate tables are a good idea and of course those intermediate tables can and should be enriched with additional data fields, that do not require a 3rd, 4th or nth table to store i.e. a simple set of dropdown options, since this can easily be handled with attributes configured in TCA, as it is shown here: https://docs.typo3.org/m/typo3/reference-tca/master/en-us/ColumnsConfig/Type/Inline/Examples.html
sys_file_reference is the most prominent example since it provides exactly that kind of additional information that should not be pumped into additional tables - and guess what, the TYPO3 core does not make use of a single line of Extbase code to deal with that data or almost any other data of the core tables.
To answer your last question: Take a look at the good old IRRE Tutorial to get a clue how to do m:n connections with intermediate inline tables.
https://docs.typo3.org/typo3cms/extensions/irre_tutorial/0.4.0/Manual/Index.html#intermediate-tables-for-m-n-relations
Depends on the issue, sometimes the intermediate table is an entity, sometimes not. In this example the intermediate table is the track, which would contain: [uid, cd, song, track_no, ... (whatever else needed to define the track)]
Be carefull when you define your data, that you do not make it too advanced.
I recently found myself using some rather lengthy names for the tables and views involved in a development piece, which got me wondering whether it's possible to create client/database/server level aliases for objects.
Say for example I have a view named dbo.vAlphaBetaGammaDelta . Is there a way (with or without Intellisense) to create a reference to it named dbo.vABGD ?
If not, would there be any downfalls to creating a view of a view or single table aside from maintenance necessary if/when the table schema changes?
I should note that these aliases/views would not be intended for use in other objects, but for alleviation and prevention of carpal tunnel during day-to-day troubleshooting and delving xD
SQL Server allows for the creation of synonyms. That seems to be what you are looking for: http://msdn.microsoft.com/en-us/library/ms177544.aspx
However, as #MitchWheat mentioned. this seems to be going in the wrong direction. There are a few quite good SSMS plugins available that provide auto completion of long object names (e.g. SQL Prompt). Incidentally those products have trouble with synonyms...
There are many cases where you would like to have synonyms.
Let me state just one for start:
You have a well defined hypothetical name of a table: GlobalStatisticalRecord. Hundreds of lines of code and objects (keys, indexes, etc.) in SQL and elsewhere are referring to this table name.
After 5 years of usage, the abbreviation GSR was accustomed not only among the technical people, but also among the business users. So, to stress again, GSR is now even more recognizable than GlobalStatisticalRecord. However, for the new people that come into the technical team, it is good to keep the name GlobalStatisticalRecord as a table name, since it nicely describes what is the table all about. Now, when writing a quick adhoc query - and that may not be from your tool of choice with all the Intellisense features you are accustom to - then these aliases are really saving your time (and "life" at 2am in the morning when you are frantically trying to diagnose a production problem).
Please, if you never faced a case when you would need this, just don't assume that there is none.
I stressed the adhoc adjective, since I agree that in permanent queries (stored procedures, etc.), for the reasons you pointed out, it is advisable to use the full table names.
I've got a table used for issue tracking (kind of like stackoverflow :) to log PC related issues) and for simplicity I'll narrow it down to a few fields, something like the following:
Site Category Issue
MI Office Software My MS word does not run macros.
CL Office Hardware PC memory needs to be upgraded
MX Office Printer Printer is out of memory.
MI Office Software Office product prompts for allowing macro to run
I want to find related issues when I am looking at for instance one issue. I can't really use the LIKE operator as for instance if I do:
SELECT...FROM...WHERE Issue LIKE '%My MS word does not run macros.%'
Would only return the first record. Do I have to figure out how to pull key words like "Macros" ? How would I find related records so that my query for instance could return records 1 and 4. Or return 2 and 3 together?
Well here are 3 ways to go about it..
1. Best case:
We have the users add 'tags' to each issue. This way users can search issues using tags and find related issues too. (Just like http://stackoverflow.com ;) )
This could be implemented creating two new tables:
tag_metadata (tag#, name, description, ...)
tag_issue_relationship(tag#, issue#)
We could go a step further and add weight to each issue entry that will determine its position in the similar issue search/look-up ranking.
2. Average case:
We have more levels to sub-categories to help further classify the problem. Now thinking of change control, will your system support easily adding/removing/re-arranging the category hierarchy over time..?
3. Worst case:
Lets say, the users are very lazy and don't want to spend a few seconds tagging their issues :).. Then you would have to implement an indexing algorithm that picks up keywords (nouns) for the issue description and builds indexes to facilitate finding 'similar' issues. Now many-a-times we may have keywords in the description that may not be significant and would result in false positives.
[Update]
Basically the solution what you are looking for could be broken up into these modules:
Parser: Will extract significant keywords from the issue description. A custom dictionary list of keywords would be used as the lookup table.
Indexer: Would index these keywords to make it searchable. This involves maintaining forward and reverse indices!
Search: Would use the indexes to locate 'similar' issues.
There may be an existing commercial/open-source product that does this..
I'm new to Workflow Foundation. I've worked my way through one book (K. Scott Allen's Programming Windows Workflow Foundation) which was okay but I'm left with several questions. The biggest one is 'where do I put the data'?
Throughout the book he uses the idea of a Bug Tracking system; the scenario isn't too far from what I want to do. His examples use a simple Bug class with three properties and nothing else and he just makes it a field on his activities and passes it around where necessary. But in the real world a bug report would probably have lines of text that you'd want to be searchable; my scenario certainly does. If all of this text is squirrelled away by the persistence service, how do I get at it for text searches?
In the real world, what do you do with your data?
For simple keys or assciated foreign keys you can use the tracking service to store such key/value pairs in the database too and query them later by using the tracking information in the tracking tables.
For full text search you can store the data in additonal tables you are creating side-by-side to the original tables of the sql-persistence-service. You have to manually add and delete them in case of workflow ending or error.
I need to test whether various types of database objects exist in a given database, and I don't know how to formulate these tests in Firebird SQL. Each test has the form "Does object of type X with name Y exist?". For example, I need to test whether a table with a given name exists. The object types I need to test are:
Table
View
Domain
Trigger
Procedure
Exception
Generate
UDF
Role
One can find how to query for a given table on the Internet, but the other types are more difficult to find ...
I think a lot of what you are asking can be found at this forum post. If you want to dive a little deeper, this site seems to have a graphical representation of the tables.
It seems like you need to query against the system tables to reliably get that information. Here's a tutorial that looks like it can help:
http://www.alberton.info/firebird_sql_meta_info.html
Every year, Martijn Tonies made a session in Firebird Conference
so find in timetable
in 2005
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=fb_conf_timetable_2005
in 2006
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=fb_conf_timetable_2006
there is also for 2007 and 2008
http://www.firebirdconference.net/index.php?option=com_content&view=article&id=3&Itemid=3
but I don't know where to download papers