Skip to main content
replaced http://data.stackexchange.com/ with https://data.stackexchange.com/
Source Link

I'll be using this querythis query. In normal operation mode The Stack Exchange Data Explorer, SEDESEDE, will only query one specific site. Luckily the databases for all sites are in the same instance and can be queried.

From the data-dictionary we learn that the users table does not have a column that indicates if a user is a Stack Exchange employee (or subcontractor, what ever that means to you). For this I added a temp table that we are populating with accountid's from Stack Exchange employees. I've done two as an example. You can add the remaining id's yourself, if you're interested, by forkingforking my query.

You can export this result to a csv filecsv file to do your statistical analysis in Excel or add grouping and calculations to the last select statement.

I'll be using this query. In normal operation mode The Stack Exchange Data Explorer, SEDE, will only query one specific site. Luckily the databases for all sites are in the same instance and can be queried.

From the data-dictionary we learn that the users table does not have a column that indicates if a user is a Stack Exchange employee (or subcontractor, what ever that means to you). For this I added a temp table that we are populating with accountid's from Stack Exchange employees. I've done two as an example. You can add the remaining id's yourself, if you're interested, by forking my query.

You can export this result to a csv file to do your statistical analysis in Excel or add grouping and calculations to the last select statement.

I'll be using this query. In normal operation mode The Stack Exchange Data Explorer, SEDE, will only query one specific site. Luckily the databases for all sites are in the same instance and can be queried.

From the data-dictionary we learn that the users table does not have a column that indicates if a user is a Stack Exchange employee (or subcontractor, what ever that means to you). For this I added a temp table that we are populating with accountid's from Stack Exchange employees. I've done two as an example. You can add the remaining id's yourself, if you're interested, by forking my query.

You can export this result to a csv file to do your statistical analysis in Excel or add grouping and calculations to the last select statement.

replaced http://meta.stackexchange.com/ with https://meta.stackexchange.com/
Source Link

From the data-dictionarydata-dictionary we learn that the users table does not have a column that indicates if a user is a Stack Exchange employee (or subcontractor, what ever that means to you). For this I added a temp table that we are populating with accountid's from Stack Exchange employees. I've done two as an example. You can add the remaining id's yourself, if you're interested, by forking my query.

From the data-dictionary we learn that the users table does not have a column that indicates if a user is a Stack Exchange employee (or subcontractor, what ever that means to you). For this I added a temp table that we are populating with accountid's from Stack Exchange employees. I've done two as an example. You can add the remaining id's yourself, if you're interested, by forking my query.

From the data-dictionary we learn that the users table does not have a column that indicates if a user is a Stack Exchange employee (or subcontractor, what ever that means to you). For this I added a temp table that we are populating with accountid's from Stack Exchange employees. I've done two as an example. You can add the remaining id's yourself, if you're interested, by forking my query.

added language hints and link to the data dictionary and fork option
Source Link
rene Mod
  • 92.1k
  • 17
  • 245
  • 516

I'll be using this query. In normal operation mode The Stack Exchange Data Explorer, SEDE, will only query one specific site. Luckily the databases for all sites are in the same instance and can be queried.

select db_name()
     , u.id
     , count(*)
from posts p 
inner join users u on u.id = p.owneruserid 
where u.accountid in (1190) 
group by u.id
select db_name()
     , u.id
     , count(*)
from posts p 
inner join users u on u.id = p.owneruserid 
where u.accountid in (1190) 
group by u.id

TheFrom the data-dictionary we learn that the users table does not have a column that indicates if a user is a Stack Exchange employee (or subcontractor, what ever that means to you). For this I added a temp table that we are populating with accountid's from Stack Exchange employees. I've done two as an example. You can add the remaining id's yourself, if you're interested, by forking my query.

create table #emp_acc (accountid integer);
-- add account id's here 
-- for example for Oded (select accountid from users where id = 1583)
insert into #emp_acc values(1190); -- Oded
insert into #emp_acc values(37099); -- Anna Lear

-- all databases
declare  db_c cursor for select [name] 
                         from sys.databases 
                         where database_id > 5 -- skip master, temp, model, msdb, Data.SE

declare @db_c_name sysname   -- holds name of db after fetch
declare @sql nvarchar(max) -- holds build up sql string

-- result table
create table #emp_post_cnt ( db sysname
                            , displayname nvarchar(200)
                            , posts integer
                            , tot integer);
                            
open db_c
fetch next from db_c into @db_c_name
while(@@FETCH_STATUS = 0)
begin
    set @sql = N'use '+ QUOTENAME(@db_c_name) +';
           insert into #emp_post_cnt 
           select db_name()
           , u.displayname 
           , count(*) 
           , (select count(*) from posts) 
           from posts p 
           inner join users u on u.id = p.owneruserid 
           inner join #emp_acc a on a.accountid = u.accountid 
           group by u.displayname;'
    exec (@sql)
   fetch next from db_c into @db_c_name
end;
close db_c;
deallocate db_c;

select db
     , displayname
     , posts 
     , tot
from #emp_post_cnt

drop table #emp_post_cnt
drop table #emp_acc
create table #emp_acc (accountid integer);
-- add account id's here 
-- for example for Oded (select accountid from users where id = 1583)
insert into #emp_acc values(1190); -- Oded
insert into #emp_acc values(37099); -- Anna Lear

-- all databases
declare  db_c cursor for select [name] 
                         from sys.databases 
                         where database_id > 5 -- skip master, temp, model, msdb, Data.SE

declare @db_c_name sysname   -- holds name of db after fetch
declare @sql nvarchar(max) -- holds build up sql string

-- result table
create table #emp_post_cnt ( db sysname
                            , displayname nvarchar(200)
                            , posts integer
                            , tot integer);
                            
open db_c
fetch next from db_c into @db_c_name
while(@@FETCH_STATUS = 0)
begin
    set @sql = N'use '+ QUOTENAME(@db_c_name) +';
           insert into #emp_post_cnt 
           select db_name()
           , u.displayname 
           , count(*) 
           , (select count(*) from posts) 
           from posts p 
           inner join users u on u.id = p.owneruserid 
           inner join #emp_acc a on a.accountid = u.accountid 
           group by u.displayname;'
    exec (@sql)
   fetch next from db_c into @db_c_name
end;
close db_c;
deallocate db_c;

select db
     , displayname
     , posts 
     , tot
from #emp_post_cnt

drop table #emp_post_cnt
drop table #emp_acc

You can export this result to Excela csv file to do your statistical analysis therein Excel or add grouping and calculations to the last select statement.

I'll be using this query. In normal operation mode SEDE will only query one specific site. Luckily the databases for all sites are in the same instance and can be queried.

select db_name()
     , u.id
     , count(*)
from posts p 
inner join users u on u.id = p.owneruserid 
where u.accountid in (1190) 
group by u.id

The users table does not have a column that indicates if a user is a Stack Exchange employee (or subcontractor, what ever that means to you). For this I added a temp table that we are populating with accountid's from Stack Exchange employees. I've done two as an example. You can add the remaining id's yourself if you're interested.

create table #emp_acc (accountid integer);
-- add account id's here 
-- for example for Oded (select accountid from users where id = 1583)
insert into #emp_acc values(1190); -- Oded
insert into #emp_acc values(37099); -- Anna Lear

-- all databases
declare  db_c cursor for select [name] 
                         from sys.databases 
                         where database_id > 5 -- skip master, temp, model, msdb, Data.SE

declare @db_c_name sysname   -- holds name of db after fetch
declare @sql nvarchar(max) -- holds build up sql string

-- result table
create table #emp_post_cnt ( db sysname
                            , displayname nvarchar(200)
                            , posts integer
                            , tot integer);
                            
open db_c
fetch next from db_c into @db_c_name
while(@@FETCH_STATUS = 0)
begin
    set @sql = N'use '+ QUOTENAME(@db_c_name) +';
           insert into #emp_post_cnt 
           select db_name()
           , u.displayname 
           , count(*) 
           , (select count(*) from posts) 
           from posts p 
           inner join users u on u.id = p.owneruserid 
           inner join #emp_acc a on a.accountid = u.accountid 
           group by u.displayname;'
    exec (@sql)
   fetch next from db_c into @db_c_name
end;
close db_c;
deallocate db_c;

select db
     , displayname
     , posts 
     , tot
from #emp_post_cnt

drop table #emp_post_cnt
drop table #emp_acc

You can export this result to Excel to do your statistical analysis there or add grouping and calculations to the last select statement.

I'll be using this query. In normal operation mode The Stack Exchange Data Explorer, SEDE, will only query one specific site. Luckily the databases for all sites are in the same instance and can be queried.

select db_name()
     , u.id
     , count(*)
from posts p 
inner join users u on u.id = p.owneruserid 
where u.accountid in (1190) 
group by u.id

From the data-dictionary we learn that the users table does not have a column that indicates if a user is a Stack Exchange employee (or subcontractor, what ever that means to you). For this I added a temp table that we are populating with accountid's from Stack Exchange employees. I've done two as an example. You can add the remaining id's yourself, if you're interested, by forking my query.

create table #emp_acc (accountid integer);
-- add account id's here 
-- for example for Oded (select accountid from users where id = 1583)
insert into #emp_acc values(1190); -- Oded
insert into #emp_acc values(37099); -- Anna Lear

-- all databases
declare  db_c cursor for select [name] 
                         from sys.databases 
                         where database_id > 5 -- skip master, temp, model, msdb, Data.SE

declare @db_c_name sysname   -- holds name of db after fetch
declare @sql nvarchar(max) -- holds build up sql string

-- result table
create table #emp_post_cnt ( db sysname
                            , displayname nvarchar(200)
                            , posts integer
                            , tot integer);
                            
open db_c
fetch next from db_c into @db_c_name
while(@@FETCH_STATUS = 0)
begin
    set @sql = N'use '+ QUOTENAME(@db_c_name) +';
           insert into #emp_post_cnt 
           select db_name()
           , u.displayname 
           , count(*) 
           , (select count(*) from posts) 
           from posts p 
           inner join users u on u.id = p.owneruserid 
           inner join #emp_acc a on a.accountid = u.accountid 
           group by u.displayname;'
    exec (@sql)
   fetch next from db_c into @db_c_name
end;
close db_c;
deallocate db_c;

select db
     , displayname
     , posts 
     , tot
from #emp_post_cnt

drop table #emp_post_cnt
drop table #emp_acc

You can export this result to a csv file to do your statistical analysis in Excel or add grouping and calculations to the last select statement.

Source Link
rene Mod
  • 92.1k
  • 17
  • 245
  • 516
Loading