easiest way for beginner to start database?

M

mp

I know this is vague but would appreciate any general advice to give me a
quick start...
I'm new to c# and new to databases.
I want to create two tables, tblBidders, tblProjects
tblBidders will list companies
tblProjects will list projects
one view would show projects
pick project and see list of all bidders
other view would show bidders
pick bidder and see list of all projects bidding on

any tips for easiest place to start?
eg which control to show datatable on form
would wpf or winform be better/easier ?
sqlite or ado.net
etc

thanks
mark
 
R

RayLopez99

I know this is vague but would appreciate any general advice to give me a
quick start...
I'm new to c# and new to databases.
I want to create two tables, tblBidders, tblProjects
tblBidders will list companies
tblProjects will list projects
one view would show projects
    pick project and see list of all bidders
other view would show bidders
    pick bidder and see list of all projects bidding on

any tips for easiest place to start?
eg which control to show datatable on form
would wpf or winform be better/easier ?
sqlite or ado.net
etc

thanks
mark

You want an honest answer? You will not hear this from the SQL crowd,
and yes I do program in ADO.NET, but the easiest, fastest and for you
the best way is to forget databases entirely, and go the XML route.
Simply put your data into an XML file, and read/write from it. You
can use XML as a source for listboxes, comboboxes, etc. Once you
populate your list box, you can sort too (built into listboxes). If
you program in WPF it's just like a database for most people. BTW
your idea of a 'database' is probably not a real database. A real
database is normalized according to Cobb's rules, with cryptic and non-
redudant info (typically you cannot make head or tails out of the raw
data in a true database, it's so broken up and atomized) and believe
you me, unless you want to take a time out of at least 6 months to
learn that stuff (like I did), you don't want to go down that road.
XML it. A book by Bipin Joshi is decent on XML, but any textbook tells
you about XML. Also you'll use LINQ over SQL commands, which are
easier to learn. If you insist on databases only buy the books by
Sceppa--the rest are trash.

Caveat emptor. You might get answers from Peter and others here who
think I am a troll and that might lead you astray--don't listen to
them. You've been warned. If you do want to learn about databases
that's fine, but like I say it won't really solve most of your
problems. I routinely use XML even though I'm pretty good by now
using SQL (and SQL commands, rather than LINQ).

RL
 
F

Family Tree Mike

You want an honest answer? You will not hear this from the SQL crowd,
and yes I do program in ADO.NET, but the easiest, fastest and for you
the best way is to forget databases entirely, and go the XML route.
Simply put your data into an XML file, and read/write from it. You
can use XML as a source for listboxes, comboboxes, etc. Once you
populate your list box, you can sort too (built into listboxes). If
you program in WPF it's just like a database for most people. BTW
your idea of a 'database' is probably not a real database. A real
database is normalized according to Cobb's rules, with cryptic and non-
redudant info (typically you cannot make head or tails out of the raw
data in a true database, it's so broken up and atomized) and believe
you me, unless you want to take a time out of at least 6 months to
learn that stuff (like I did), you don't want to go down that road.
XML it. A book by Bipin Joshi is decent on XML, but any textbook tells
you about XML. Also you'll use LINQ over SQL commands, which are
easier to learn. If you insist on databases only buy the books by
Sceppa--the rest are trash.

Caveat emptor. You might get answers from Peter and others here who
think I am a troll and that might lead you astray--don't listen to
them. You've been warned. If you do want to learn about databases
that's fine, but like I say it won't really solve most of your
problems. I routinely use XML even though I'm pretty good by now
using SQL (and SQL commands, rather than LINQ).

RL

For a previous discussion _opposed_ to this line of reasoning, please see:

http://groups.google.com/group/micr....csharp/browse_thread/thread/a184510b20bec196
 
F

Family Tree Mike

I know this is vague but would appreciate any general advice to give me a
quick start...
I'm new to c# and new to databases.
I want to create two tables, tblBidders, tblProjects
tblBidders will list companies
tblProjects will list projects
one view would show projects
pick project and see list of all bidders
other view would show bidders
pick bidder and see list of all projects bidding on

any tips for easiest place to start?
eg which control to show datatable on form
would wpf or winform be better/easier ?
sqlite or ado.net
etc

thanks
mark

I would start by following some of the MSDN walkthroughs, just google
"Sql Compact CSharp Walkthrough". The question of WPF versus winform,
does not really come into play just because your app is database driven.
More examples are available for Winforms, and frankly, in my opinion,
it's easier to understand than WPF.

Most all controls can bind to data sources, so the control choice really
depends on the purpose in the app. If showing an entire table, then
perhaps the datagridview. If showing a choice from all unique values,
then perhaps a combobox.
 
A

Arne Vajhøj

You want an honest answer? You will not hear this from the SQL crowd,
and yes I do program in ADO.NET, but the easiest, fastest and for you
the best way is to forget databases entirely, and go the XML route.
Simply put your data into an XML file, and read/write from it.

Using XML for a database that need to be updated is usually not
a good approach, because it raises a lot of concurrency issues, that
the database software solved for you.
BTW
your idea of a 'database' is probably not a real database. A real
database is normalized according to Cobb's rules,

Cobb ????

Codd maybe ?
with cryptic and non-
redudant info (typically you cannot make head or tails out of the raw
data in a true database, it's so broken up and atomized)

Most people manage to understand normalized databases fine.

Arne
 
M

mp

Thanks
mark

Family Tree Mike said:
I would start by following some of the MSDN walkthroughs, just google "Sql
Compact CSharp Walkthrough". The question of WPF versus winform, does not
really come into play just because your app is database driven. More
examples are available for Winforms, and frankly, in my opinion, it's
easier to understand than WPF.

Most all controls can bind to data sources, so the control choice really
depends on the purpose in the app. If showing an entire table, then
perhaps the datagridview. If showing a choice from all unique values,
then perhaps a combobox.
 
R

RayLopez99

Most people manage to understand normalized databases fine.

Arne

But don't forget, who said this below? And reread the OP carefully.
That guy not say he would be reading and writing at the same time. He
might think he wants to do that, but 99.9% of the time people use
databases for read only. I rest my case Arne.

RL

If your data is readonly data, then your XML files will work fine.
But if you need to update data, then supporting multiple concurrent
updates to files and recovery if somethings crashes in the middle
will be a lot of work with file and a piece of cake with
database. [NOT TRUE--HOW IS A CRASH IN THE MIDDLE OF READING AN XML
FILE A PROBLEM?--RL]

Performance wise XML files will probably perform similar to database
tables without indexes. Which is OK for the data size you list. But
I am a bit skeptical about whether you really know that data would
never grow bigger.
 
F

Family Tree Mike

Most people manage to understand normalized databases fine.

Arne

But don't forget, who said this below? And reread the OP carefully.
That guy not say he would be reading and writing at the same time. He
might think he wants to do that, but 99.9% of the time people use
databases for read only. I rest my case Arne.

RL

If your data is readonly data, then your XML files will work fine.
But if you need to update data, then supporting multiple concurrent
updates to files and recovery if somethings crashes in the middle
will be a lot of work with file and a piece of cake with
database. [NOT TRUE--HOW IS A CRASH IN THE MIDDLE OF READING AN XML
FILE A PROBLEM?--RL]

Updating, means writing, not reading. A crash during that is very bad...
 
R

RayLopez99

database. [NOT TRUE--HOW IS A CRASH IN THE MIDDLE OF READING AN XML
FILE A PROBLEM?--RL]

Updating, means writing, not reading.  A crash during that is very bad....

True enough I suppos, but I've used XML extensively (outside a DB
context) and I think a crash in the middle of a update (write) would
be rare. And I'm not sure that a crash in the middle of an UPDATE in
a DB (at the server end) would not corrupt the DB as well.

BTW, in Silverlight, SQL is not supported (as of yet) so that' s
another reason to use XML.

RL
 
V

vanderghast

Start with MS SQL Server Developer (to have all the required tools).

Create a table Bidders (forget the prefixing, instead, use the plural for a
table, singular for fields) with at least, one field, bidder name, or bidder
id, and other fields as what belong to the said bidder, independently of any
project (such as address, phone, ... ).

Create your table Projects, with only data that occurs once for the project
(such as its name, where it is, when it is due to start, etc.) independently
of any bidder.

Create a table ProjectsBidders, two fields, the project name (or project id)
and bidder name (or bidder id). Have ONE row for each different couple (ie.
a project can have many bidders and a bidder can bid on many projects).


Fill your tables with data. You can add relations between the tables if you
want, but that is not strictly required for the demo (it would, for
integrity, though).


Now, in C#. Create new item, a "LINQ to SQL Classes" item (be sure to have
your application targeting .Net Framework 3.5). It is mostly graphical, as
it would be in Office-MS Access for a relationship windows: bring the three
tables discussed here up. That's all, for the ties to the db at least.


In code (for a windows form), create an object of the LINQ to SQL class (it
is often called a 'context' in the literature), and use LINQ over it, like:


=================
myNameSpace.MyLINQtoSQLclass dbContext = new myNameSpace.MyLINQtoSQLclass( )
;

// the LINQ to SQL class often remove the plural for you
var myQuery = from j in dbContext.ProjectsBidder
where j.BidderID == "Acme"
select j.ProjectID ;


datagridView1.DataSource = myQuery ;
=================

and this is all the database- relevant (1) code you need to display, in the
datagridView1, all the projects where the bidder is "Acme". Replace the hard
coded constant "Acme" by a control supplying this value, to make it more
versatile, but I don't want to obscure the code... it is, basically, as
simple as that!


And not very hard, isn't it?

Almost as easy as using Office-MS Access


Vanderghast, Access MVP

--------------------
(1) while it is not the WHOLE code you need to be able to run an example,
because that would include the MyLINQtoSQLclass object too, and the code
for the form, but those line of codes are automatically supplied for you by
VS2008.
 
V

vanderghast

A crash, even a power failure, won't corrupt a db like MS SQL Server,
because the pending operation would be in the log, NOT in the db itself. It
would be, in the end, like rolling back a transaction.

MS SQL supports output in XML, so I really fail to see your point, about
Silverlight.


It would be fine to mention that the job could be done in XML under some
circumstances, and on that, I would have nothing to say, but to make general
claim about something you don't know is impertinent and a blow to your
credibility, by none other than yourself, imho.

Vanderghast, Access MVP


database. [NOT TRUE--HOW IS A CRASH IN THE MIDDLE OF READING AN XML
FILE A PROBLEM?--RL]

Updating, means writing, not reading. A crash during that is very bad...

True enough I suppos, but I've used XML extensively (outside a DB
context) and I think a crash in the middle of a update (write) would
be rare. And I'm not sure that a crash in the middle of an UPDATE in
a DB (at the server end) would not corrupt the DB as well.

BTW, in Silverlight, SQL is not supported (as of yet) so that' s
another reason to use XML.

RL
 
R

RayLopez99

A crash, even a power failure, won't corrupt a db like MS SQL Server,
because the pending operation would be in the log, NOT in the db itself. It
would be, in the end, like rolling back a transaction.

Thanks for pointing that out--I forgot about rollback and atomic
transactions.
MS SQL supports output in XML, so I really fail to see your point, about
Silverlight.

Silverlight does not support SQL at the moment--not sure about release
4, but 3 and before don't. That's my point.
It would be fine to mention that the job could be done in XML under some
circumstances, and on that, I would have nothing to say, but to make general
claim about something you don't know is impertinent and a blow to your
credibility, by none other than yourself, imho.

No, I have used SQL extensively. I am proficient in it. Not as good
as you perhaps, but I can move about in it freely.

RL
 
R

Registered User

Silverlight does not support SQL at the moment--not sure about release
4, but 3 and before don't. That's my point.
There are a number of reasons why Silverlight both shouldn't and can't
directly interact with a local or remote SQL server. With some thought
and perhaps a review of what Silverlight is and how it works, many
these reasons should become obvious.

The third tutorial at silverlight.net involves accessing an SQL
database with a WCF service and LINQ.
http://silverlight.net/learn/tutorials/sqldatagrid-cs/

regards
A.G.
 
M

mp

Thanks, will study that
mark

vanderghast said:
Start with MS SQL Server Developer (to have all the required tools).

Create a table Bidders (forget the prefixing, instead, use the plural for
a table, singular for fields) with at least, one field, bidder name, or
bidder id, and other fields as what belong to the said bidder,
independently of any project (such as address, phone, ... ).

Create your table Projects, with only data that occurs once for the
project (such as its name, where it is, when it is due to start, etc.)
independently of any bidder.

Create a table ProjectsBidders, two fields, the project name (or project
id) and bidder name (or bidder id). Have ONE row for each different couple
(ie. a project can have many bidders and a bidder can bid on many
projects).


Fill your tables with data. You can add relations between the tables if
you want, but that is not strictly required for the demo (it would, for
integrity, though).


Now, in C#. Create new item, a "LINQ to SQL Classes" item (be sure to
have your application targeting .Net Framework 3.5). It is mostly
graphical, as it would be in Office-MS Access for a relationship windows:
bring the three tables discussed here up. That's all, for the ties to the
db at least.


In code (for a windows form), create an object of the LINQ to SQL class
(it is often called a 'context' in the literature), and use LINQ over it,
like:


=================
myNameSpace.MyLINQtoSQLclass dbContext = new
myNameSpace.MyLINQtoSQLclass( ) ;

// the LINQ to SQL class often remove the plural for you
var myQuery = from j in dbContext.ProjectsBidder
where j.BidderID == "Acme"
select j.ProjectID ;


datagridView1.DataSource = myQuery ;
=================

and this is all the database- relevant (1) code you need to display, in
the datagridView1, all the projects where the bidder is "Acme". Replace
the hard coded constant "Acme" by a control supplying this value, to make
it more versatile, but I don't want to obscure the code... it is,
basically, as simple as that!


And not very hard, isn't it?

Almost as easy as using Office-MS Access


Vanderghast, Access MVP

--------------------
(1) while it is not the WHOLE code you need to be able to run an example,
because that would include the MyLINQtoSQLclass object too, and the code
for the form, but those line of codes are automatically supplied for you
by VS2008.
 
R

RayLopez99

Thanks, will study that
mark

Like I said, you would do better to use XML and populate a list. XML
is a text file and much, much easier to work with, unless you want to
do 100s of users and deal with atomic transactions.

But at this point I'm sure you're committed to learning about it the
hard way...just like I did. It's OK, as 6 months or more learning the
ins and outs of ADO.NET and SQL is not a bad investment in the long
run.

Goodbye,

RL
 
M

mp

Thanks, will study that
mark

Like I said, you would do better to use XML and populate a list. XML
is a text file and much, much easier to work with, unless you want to
do 100s of users and deal with atomic transactions.

But at this point I'm sure you're committed to learning about it the
hard way...just like I did. It's OK, as 6 months or more learning the
ins and outs of ADO.NET and SQL is not a bad investment in the long
run.

Goodbye,

RL

hi ray
i'm committed to try to learn everything - but it all takes time and i'm
slow learner...have to learn how to set up xml and some forms for the ui
part
i understand a bit about tables and fields but nothign about how i would
emulate that in xml...
i've read bits about xml, understand a bit about the heirarchical nature,
but am hoping to find some actual samples to get me started...it's a long
climb up from where i'm at :)
i appreciate your input, and everyones...just takes me a while to research
it all, i'll search for some close samples i can maybe tweak

seems i've seen some db samples that may have a grid like display with next
previous buttons etc that may be a head start with the db option...
i'll see if there's anything siimilar with the xml option...
this isn't a multiuser high usage project with national security
consequences..., just simple lookup functionality in a kind of cross
reference two tables kind of format...

thanks
mark
 
A

Arne Vajhøj

But don't forget, who said this below? And reread the OP carefully.
That guy not say he would be reading and writing at the same time. He
might think he wants to do that, but 99.9% of the time people use
databases for read only. I rest my case Arne.

99% of database do get updated.

And a database as the one described by the original
poster certainly needs to be updated.
If your data is readonly data, then your XML files will work fine.
But if you need to update data, then supporting multiple concurrent
updates to files and recovery if somethings crashes in the middle
will be a lot of work with file and a piece of cake with
database. [NOT TRUE--HOW IS A CRASH IN THE MIDDLE OF READING AN XML
FILE A PROBLEM?--RL]

It is not.

But it is also mentioned as a problem when *UPDATING* data, so ...

Arne
 
A

Arne Vajhøj

database. [NOT TRUE--HOW IS A CRASH IN THE MIDDLE OF READING AN XML
FILE A PROBLEM?--RL]

Updating, means writing, not reading. A crash during that is very bad...

True enough I suppos, but I've used XML extensively (outside a DB
context) and I think a crash in the middle of a update (write) would
be rare.

If loosing data being rare is good enough, then a lot of
things is possible.

But usually people care about their data.
And I'm not sure that a crash in the middle of an UPDATE in
a DB (at the server end) would not corrupt the DB as well.

The DB should recover fine (if it is a database server with a log
file - MS SQLServer, IBM DB2, Oracle DB, Sybase ASE,
MySQL with InnoDB tables, PostgreSQL etc.).

That is what databases do.
BTW, in Silverlight, SQL is not supported (as of yet) so that' s
another reason to use XML.

SL----web service----database

works fine.

For rather obvious reasons no one would want to do:

SL----database

Arne
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top