can anyone tell me about relationship on typo 3? e.g. i got 2 tables, 'A' and 'B', currently i got simple form that can inserting data into 'A' table, the 'A' table fields are "name","id_types","address". the "id_types" is foreign_key from 'B' table. And the 'B' table fields are "id_types","types_name". How can i make this relation on typo 3?
is it something to do with persistence_object_identifier?
this is my code for trying manually adding into second table
public function createartistAction(Artist $artist)
{
$artisttype = new Artisttype();
$artisttype->setArtisttype_name($artist->getArtisttype_id());
$this->ArtisttypeRepository->add($artisttype);
$datenow = date('d/m/Y');
$date = date_create($datenow);
$artist->setCreated_at($date);
$artist->setUpdated_at($date);
$this->addFlashMessage('Artist Created.');
$this->ArtistRepository->add($artist);
$this->redirectToUri('/artist/viewArtist');
}
any help would be much appreciated.
thanks
I guess that is here to get you started:
http://docs.typo3.org/flow/TYPO3FlowDocumentation/TheDefinitiveGuide/PartII/Modeling.html
All relationship in TYPO3 Flow is done in the mvc model and it uses various design patterns to make it easy for the programmer. So in your case the best way would be not to even touch the database by itself but use the opportunities the php framework offers.
It's not a fast solution and maybe one have to read a lot before one can start. But once you understand it, it's a pretty handy way to get your data structured.
Related
I am confused on how to get this to work. I have tried a few different ways to get this to work and I am trying to find the best solution. I have about 10 case statements that need to reference another table for verification. So instead of typing out each exclusion and inclusion I created a table. This works with SAS and works with SQL, though HIVE is the troublemaker.
The CPX.CHP and ONC.ODCD have a list of codes/numbers/etc.
When ((main.refrl_req_by_desc in ('MM', 'HP') AND (main.refrl_req_rsn_desc in ('CCM'))) AND (main.PRIMP = CPX.CHP) AND (main.PRIMD != ONC.ODCD)) then 2
Appreciate any guidance on this.
Good morning! I am currently working on creating a postgreSQL database with some client information, however I ran into an issue which I wasn't able to solve with my basic knowledge of SQL. Searching for this method also returned with no results which I found useful or applicable.
I have two tables: 'mskMobile' and 'emailData'. Both of those tables contain a column named 'email' and some of those emails overlap. I figured out that I can view those intersecting emails by requesting
SELECT "mailData".email
FROM "mailData"
JOIN "mskMobile"
ON "mailData".email="mskMobile".email;
Now I want to write the data of two other columns of those common rows in 'mskMobile' named 'name' and 'surname' to the corresponding columns in 'emailData' (named identically), however I cannot find any answer on how to do so. Any suggestions on how to execute this action?
UPDATE "mksMobile" SET name = "mailData".name, surname = "mailData".surname
FROM "mailData"
WHERE "mailData".email = "mskMobile".email;
After a bit more research I came up with a following way of declaring it:
SELECT "mailData".email, "mskMobile".num, "mskMobile".name
FROM "mailData"
INNER JOIN "mskMobile"
ON "mailData".email="mskMobile".email;
This allowed me to build a new table with the data combined.
I wonder why is Entity framework generating such an inefficient SQL query. In my code I expected the WHERE to act upon the INCLUDE:
db.Employment.Where(x => x.Active).Include(x => x.Employee).Where(x => x.Employee.UserID == UserID)
but I ended up with a double SQL JOIN:
SELECT [x].[ID], [x].[Active], [x].[CurrencyID], [x].[DepartmentID], [x].[EmplEnd], [x].[EmplStart], [x].[EmployeeID], [x].[HolidayGroupID], [x].[HourlyCost], [x].[JobTitle], [x].[ManagerID], [x].[WorkScheduleGroupID], [e].[ID], [e].[Active], [e].[Address], [e].[BirthDate], [e].[CitizenshipID], [e].[City], [e].[CountryID], [e].[Email], [e].[FirstName], [e].[Gender], [e].[LastName], [e].[Note], [e].[Phone], [e].[PostalCode], [e].[TaxNumber], [e].[UserID]
FROM [Employment] AS [x]
INNER JOIN [Employee] AS [x.Employee] ON [x].[EmployeeID] = [x.Employee].[ID]
INNER JOIN [Employee] AS [e] ON [x].[EmployeeID] = [e].[ID]
WHERE ([x].[Active] = 1) AND ([x.Employee].[UserID] = #__UserID_0)
I found out that this query will create better SQL:
db.Employment.Where(x => x.Active).Where(x => x.Employee.UserID == UserID)
SELECT [x].[ID], [x].[Active], [x].[CurrencyID], [x].[DepartmentID], [x].[EmplEnd], [x].[EmplStart], [x].[EmployeeID], [x].[HolidayGroupID], [x].[HourlyCost], [x].[JobTitle], [x].[ManagerID], [x].[WorkScheduleGroupID]
FROM [Employment] AS [x]
INNER JOIN [Employee] AS [x.Employee] ON [x].[EmployeeID] = [x.Employee].[ID]
WHERE ([x].[Active] = 1) AND ([x.Employee].[UserID] = #__UserID_0)
However, the problem here that referenced entities are not retrieved from the DB.
Why don't two codes produce same SQLs?
The SQL is different because the statments are different.
Entity Framework does produce inefficient TSQL, it always has. By abstracting the subtleties that are necessary for SQL with good performance and replacing them with "belt and braces" nearly always work alternatives you sacrafice performance for utility.
If you need good performance, write the SQL yourself. Dapper works well for me. You can't realistically expect a "one size fits all" solution to come up with the best code for your specific situation. You can do this across the board or just where you need to.
Unless you have high volume or specific performance requirements get on with it and use whatever you find easiest. If you need to tune your queries to your database you are going to have learn the details of your database engine and implement the queries yourself. If you are expecting the next iteration of Entity Framework to be the magic bullet that allows you fast, efficient SQL data access with minimal knowledge, good luck.
P.S.
Off-topic but, NoSQL probably isn't the answer either, is just a different class of database.
I have built a pretty big application with Zend and i was wondering which would be better, building query by hand (using the Zend object model)
$db->select()
->form('table')
->join('table2',
'table.id = table2.table_id')
or going with the findDependentRowset method (Zend doc for findDependentRowSet).
I was wondering since i did a test to fetch data over multiple tables and display all the informations from a table and the findDependentRowset seemed to run slower. I might be wrong but i guess it makes a new query every time findDependentRowset is called as in :
$table1 = new Model_Table1;
$rowset = $table1-fetchAll();
foreach($rowset as $row){
$table2data = $row->findDependentRowset('Model_Table2', 'Map');
echo $row['field'] . ' ' . $table2data['field'];
}
So, which one is better and is there a way using findDependentRowset to build complexes queries that could span over 5 tables which would run as fast as a hand made query?
Thanks
Generally, build your own query is the best way to go, because zend will create just one object (or set of objects) and do just one query.
If you use findDependentRowset Zend will perform another query and build another object (or set) with the result for each call.
You should use this only in very specific cases.
See this question: PHP - Query single value per iteration or fetch all at start and retrieve from array?
This is probably a super simple question, but I'm struggling to come up with the right keywords to find it on Google.
I have a Postgres table that has among its contents a column of type text named content_type. That stores what type of entry is stored in that row.
There are only about 5 different types, and I decided I want to change one of them to display as something else in my application (I had been directly displaying these).
It struck me that it's funny that my view is being dictated by my database model, and I decided I would convert the types being stored in my database as strings into integers, and enumerate the possible types in my application with constants that convert them into their display names. That way, if I ever got the urge to change any category names again, I could just change it with one alteration of a constant. I also have the hunch that storing integers might be somewhat more efficient than storing text in the database.
First, a quick threshold question of, is this a good idea? Any feedback or anything I missed?
Second, and my main question, what's the Postgres command I could enter to make an alteration like this? I'm thinking I could start by renaming the old content_type column to old_content_type and then creating a new integer column content_type. However, what command would look at a row's old_content_type and fill in the new content_type column based off of that?
If you're finding that you need to change the display values, then yes, it's probably a good idea not to store them in a database. Integers are also more efficient to store and search, but I really wouldn't worry about it unless you've got millions of rows.
You just need to run an update to populate your new column:
update table_name set content_type = (case when old_content_type = 'a' then 1
when old_content_type = 'b' then 2 else 3 end);
If you're on Postgres 8.4 then using an enum type instead of a plain integer might be a good idea.
Ideally you'd have these fields referring to a table containing the definitions of type. This should be via a foreign key constraint. This way you know that your database is clean and has no invalid values (i.e. referential integrity).
There are many ways to handle this:
Having a table for each field that can contain a number of values (i.e. like an enum) is the most obvious - but it breaks down when you have a table that requires many attributes.
You can use the Entity-attribute-value model, but beware that this is too easy to abuse and cause problems when things grow.
You can use, or refer to my implementation solution PET (Parameter Enumeration Tables). This is a half way house between between 1 & 2.