easiest way for beginner to start database?
mp
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
RayLopez99
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
Family Tree Mike
For a previous discussion _opposed_ to this line of reasoning, please see:
--
Mike
Family Tree Mike
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.
--
Mike
TheMan
> On Dec 19, 4:19 pm, "mp" <nos...@Thanks.com> wrote:
>> 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
>
>
> RL
Bloated, over-generalized reply.
Short version:
"I have a brand new XML hammer and the
world is now an XML nail."
Mark Rae [MVP]
news:a1f6c95a-b497-44e9...@s31g2000yqs.googlegroups.com...
> 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.
To the OP: ignore this post completely.
Using XML as a database is *ALWAYS* the wrong answer, simply because XML
isn't a database.
--
Mark Rae
ASP.NET MVP
http://www.markrae.net
Mark Rae [MVP]
news:e2nuqDPg...@TK2MSFTNGP05.phx.gbl...
>I know this is vague but would appreciate any general advice to give me a
>quick start...
Arne Vajhøj
> On Dec 19, 4:19 pm, "mp"<nos...@Thanks.com> wrote:
>> 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
> 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
mp
mark
"Mark Rae [MVP]" <ma...@markNOSPAMrae.net> wrote in message
news:ugjcu4bg...@TK2MSFTNGP06.phx.gbl...
mp
mark
"Family Tree Mike" <FamilyT...@ThisOldHouse.com> wrote in message
news:ONsRfBZg...@TK2MSFTNGP05.phx.gbl...
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.
Family Tree Mike
> On Dec 20, 4:55 pm, Arne Vajh�j<a...@vajhoej.dk> wrote:
>
>> 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...
--
Mike
RayLopez99
wrote:
> > 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
vanderghast
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.
"mp" <nos...@Thanks.com> wrote in message
news:e2nuqDPg...@TK2MSFTNGP05.phx.gbl...
vanderghast
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
"RayLopez99" <raylo...@gmail.com> wrote in message
news:3574eff2-76fc-4816...@m25g2000yqc.googlegroups.com...
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
Registered User
<raylo...@gmail.com> wrote:
>On Dec 29, 2:56�pm, "vanderghast" <vanderghast@com> wrote:
>
>> 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.
>
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.
mp
mark
"vanderghast" <vanderghast@com> wrote in message
news:3CC81349-73B1-4932...@microsoft.com...
RayLopez99
> Thanks, will study that
> mark
> > "mp" <nos...@Thanks.com> wrote in message
> >news:e2nuqDPg...@TK2MSFTNGP05.phx.gbl...
> >>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
>
>
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
RayLopez99
>
> The third tutorial at silverlight.net involves accessing an SQL
> database with a WCF service and LINQ.http://silverlight.net/learn/tutorials/sqldatagrid-cs/
>
Thank you. Useful for those rare times that you want to use a SQL
database for read only operations from inside of Silverlight, using
WCF service. I've added this to my toolbox for such rare occasions.
RL
mp
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
Arne Vajhøj
> On Dec 20, 4:55 pm, Arne Vajh�j<a...@vajhoej.dk> wrote:
>> Most people manage to understand normalized databases fine.
> 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
Arne Vajhøj
> On Dec 22, 6:41 pm, Family Tree Mike<FamilyTreeM...@ThisOldHouse.com>
> wrote:
>>> 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
Arne Vajhøj
> On Dec 31 2009, 5:12 pm, "mp"<nos...@Thanks.com> wrote:
>> Thanks, will study that
> is a text file and much, much easier to work with, unless you want to
> do 100s of users and deal with atomic transactions.
Unless he wants to do >1 user *or* updates.
Arne
Registered User
Situations where a Silverlight app may require data from external
sources are not at all rare. It is difficult for me to even visualize
a non-trival Silverlight app which doesn't involve moving data up and
down the wire.
In any case the indirection provided by a webservice conceals the
actual data store and its type. The client deals with the DTOs
provided by the webservice. There is no reason for the client to care
if the data is read from/written to an SQL server, an XML document, a
flat file or something else.
regards
A.G.
RayLopez99
> > 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
>
That's interesting, thanks. It explains why web services are used in
this thread tutorial by Jesse Liberty explaining SL and DBs.
RL
RayLopez99
> >> Updating, means writing, not reading. A crash during that is very bad...
>
> > 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 useXML.
>
> SL----web service----database
>
> works fine.
I bought a book by Papa called Data Driven Services for Silverlight2
that discusses setting up a web service for SL, and I was able to set
up and consume a simple web service. Thanks to you and A.G. of this
thread.
But I stand by my statement that XML is a cheap and easy way to mimic
a database. For example, nearly every example I see uses XML or hard
coded values, not a SQL query and a dB, to populate a list, GridView /
DataGrid, or combo box for example.
RL