我有一个包含两个表的数据库.这两个表都是相关的,并且具有相同的关键字段.例如,它们都具有对应于ISBN = 12345的数据行,但是这两个表具有关于该ISBN的不同数据.
所以,我试图弄清楚如何将两个表中的数据显示到一个dataGridView中.我尝试过在网上找到的一些SQL命令,但看起来C#中的命令可能与普通的SQL查询不同.
假设table1具有以下字段:ISBN,颜色,大小和table2具有ISBN,weight字段.
我需要一种在数据网格视图中显示ISBN,颜色,大小,重量的方法.我想我必须以某种方式用适配器来做这件事.我可以单独连接并对表进行查询,并在我的datagridview中显示数据,但我无法弄清楚如何混合来自两个单独表的数据.
如果你有一个很好的资源我可以读到这个我很想拥有它,我的google-fu让我失望.
这是我现在可以使用我的数据库做的一个例子:
private void Form1_Load(object sender, EventArgs e)
{
// TODO: This line of code loads data into the 'database1DataSet.Book' table. You can move, or remove it, as needed.
this.bookTableAdapter.Fill(this.database1DataSet.Book);
string connectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + @"C:\Users\Geoff\Documents\cs 351\Database1.accdb" + ";Persist Security Info=False;";
OleDbConnection conn = new OleDbConnection(connectionString);
string query = "select * from Book where ISBN = 12345";
OleDbCommand com = conn.CreateCommand();
com.CommandText = query;
OleDbDataAdapter adapter = new OleDbDataAdapter(com);
DataSet data = new …在JOIN子句或WHERE子句中使用SQL条件更好吗？是否针对这两种方式优化了SQL引擎？它取决于发动机吗？
是否始终可以通过WHERE子句中的条件替换JOIN子句中的条件？
这里举例说明我的意思
SELECT role_.name
FROM user_role
INNER JOIN user ON user_role.user_id_ = user.id AND
user_role.user_id_ = @user_id
INNER JOIN role ON user_role.role_id = role_.id
与
SELECT role_.name
FROM user_role
INNER JOIN user ON user_role.user_id_ = user.id
INNER JOIN role ON user_role.role_id = role_.id
WHERE user.id = @user_id
假设我想显示一个完整的奖项列表,其中type ="color":
Awards Type 2013 Winner
====== ==== ===========
Blue Award color Tom
Red Award color
Green Award color Dan
为了达到这个结果,我可以在Laravel中查询如下:
$year = '2013';
$awards = DB::table('awards')
->leftJoin('winners', function($join) use ($year)
{
$join->on('awards.id','=','winners.award_id');
$join->on('winners.year','=',DB::raw("'".$year."'"));
}
->where('awards.type','color')
->get();
如果输出Laravel生成的SQL,您将看到只有WHERE子句被参数化,并且如果从不受信任的源获取它,则ON子句中的$ year 容易受到sql注入的攻击.此外,查询的缓存潜力也会降低,因为$ year会经常更改.注意:如果您认为我只是将第二个左连接条件添加到查询的WHERE,则 这些不一样.
有关如何获取查询的$ year部分的任何想法参数化？
假设我有任何连接类型的跟随加入查询(INNER/LEFT/RIGHT/FULL)
SELECT E.id, D.name, E.sal from EMP E
INNER/LEFT/RIGHT/FULL JOIN DEP D
ON E.id = D.id
AND E.sal > 100
另外,我有与WHERE条件类似的查询
SELECT E.id, D.name, E.sal from EMP E
INNER/LEFT/RIGHT/FULL JOIN DEP D
ON E.id = D.id
WHERE E.sal > 100
以上查询的唯一区别是在JOIN和WHERE条件中使用E.sal> 100.
在哪种情况下,上述查询会有不同的结果 或者两者都一样吗？
我总是假设以下形式的陈述
SELECT * FROM A LEFT JOIN B ON (A.column1 = B.column2 AND B.column2 = 12321)
总是等价于
SELECT * FROM A LEFT JOIN B ON (A.column1 = B.column2)
WHERE B.column2 = 12321
更笼统地说：
SELECT * FROM A LEFT JOIN B ON (FOREIGN-KEY AND FILTER_ON(B))
WHERE FILTER_ON(A)
应该相当于
SELECT * FROM A LEFT JOIN B ON (FOREIGN-KEY)
WHERE FILTER_ON(A) AND FILTER_ON(B)
情况似乎并非如此...第一种类型提供的结果行数比第二种类型多。
问题：在哪些情况下我的假设是错误的？
准备好的查询结构和性能之间是否存在差异
select *
from employee e
join division d
on e.eid = d.eid
and e.div = d.div
and e.level > 5
and e.startDate > sysdate - interval '60' month
;
和：
select *
from employee e
join division d
on e.eid = d.eid
and e.div = d.div
where
e.level > 5
and e.startDate > sysdate - interval '60' month
;
我正在尝试使用以下方法收集数据query：
SELECT *
FROM `table1` AS `t1`
INNER JOIN `table2` AS `t2`
ON `t1`.`id`=`t2`.`id`
WHERE `t2`.`name`='myname'
看起来WHERE条件被忽略了。是否可以WHERE在连接表上应用条件？
服务器: SQL Server 2008 R2
SQL小提琴: http ://sqlfiddle.com/#!6/112a6/4/0
我为可怜的主题/标题道歉,但我很难说出如何陈述我的问题,所以我将用一个(可能)冗长的例子来画出来:
下面是一个相当简单的查询,它可以获取特定日期范围内PC的会话数.请注意,WHERE子句已被注释掉.我希望收到的是PC的完整列表,即使是在该范围内具有ZERO/NULL会话的PC.但是,当我添加WHERE子句时,我只能获得在该范围内有会话的PC.这是有问题的,因为我无法看到在此期间未使用的PC.
SELECT
f_assetnetbiosname,
COUNT(f_sessiondate) as 'Sessions'
FROM
tb_assets ass
LEFT JOIN
tb_sessions ses
ON
ses.f_sessionnetbiosname = ass.f_assetnetbiosname
--WHERE (f_sessiondate BETWEEN '04/01/2015' AND '04/30/2015')
GROUP BY f_assetnetbiosname
======================== =======================================|
| tb_assets | | tb_sessions |
======================== =======================================|
| f_assetnetbiosname | | f_sessionnetbiosname f_sessiondate |
------------------------ ---------------------------------------|
| COMP_001 | | COMP_002 03/29/2015 |
| COMP_002 | | COMP_002 03/30/2015 |
| COMP_003 | | COMP_001 03/30/2015 |
------------------------ | COMP_001 04/02/2015 …