Well, I don't usually spend time reading my code aloud :). And not everytime you are using MS Access or C# :). Eg Python uses duck-typing and after few hundreds lines of code you just can't remember what type that stupid variable content was :D.
2010/11/26 Jamie Fraser <[email protected]> > Also: see "tibbling", as this practice is known. > > > On Fri, Nov 26, 2010 at 4:05 PM, Jamie Fraser <[email protected]>wrote: > >> Yes - its completely redundant, and makes pronunciation awkward. >> >> Tables in any modern DB environment are easy to identify. Prefixing them >> with "tbl" is often a carry-over from MS Access. >> >> >> On Fri, Nov 26, 2010 at 3:52 PM, Processor Devil < >> [email protected]> wrote: >> >>> Why not? Now I don't want to hear anything about best practices, I also >>> had times when using variables like tblSomething, strSomething, fltSomething >>> and it still worked. Is there any other problem in that than simply screwing >>> some programmer's ethics? >>> >>> 2010/11/26 Jamie Fraser <[email protected]> >>> >>> Good advice, but whatever you do, don't prefix your tables with "tbl"! >>>> >>>> >>>> On Fri, Nov 26, 2010 at 10:46 AM, Benj Nunez <[email protected]>wrote: >>>> >>>>> Hello Derek, >>>>> >>>>> >>>>> After carefully reading your statement. I imagine that you need to >>>>> create two(2) tables: >>>>> >>>>> >>>>> tblLineItem >>>>> AreaID (fk) >>>>> >>>>> >>>>> ==================== >>>>> >>>>> tblArea >>>>> AreaID (pk) >>>>> AreaAmount >>>>> >>>>> >>>>> You are right to separate the "Area" part since this is the only one >>>>> that is "variable" or >>>>> constantly changing. I am also thinking that in code, this would have >>>>> been a >>>>> Collection (e.g. List<Area> myArea). My question is, do you intend to >>>>> populate >>>>> the Area separately? Do you require users to provide you this data? If >>>>> so, you can >>>>> definitely define and use collections for that. Save the collections >>>>> to the tblArea. >>>>> Then when the time comes to display what you have on your screen >>>>> (Winform or Web page), >>>>> write a query to pull those entries off from the tblLineItem together >>>>> with the tblArea (do a sql join). >>>>> >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Benj >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Nov 26, 3:27 am, Derek <[email protected]> wrote: >>>>> > I have an application where I want to present data in rows, for >>>>> > editing, but I have a variable number of columns depending on the >>>>> > configuration for that installation. Here's a rough overview; >>>>> > >>>>> > Line Item 1 | Area 1 | Area 2 | Area 3 | ... | Area N | Total All >>>>> > Areas >>>>> > Line Item 2 | Area 1 | Area 2 | Area 3 | ... | Area N | Total All >>>>> > Areas >>>>> > >>>>> > (only the area amounts would be editable) >>>>> > >>>>> > I previously had all Area columns defined in a single row, but in >>>>> some >>>>> > installations I need more or less areas. I've modified the database >>>>> so >>>>> > that it's properly normalized, so the end table is something like; >>>>> > >>>>> > LineItemID (fk) >>>>> > AreaID (fk) >>>>> > AreaAmount (my data value) >>>>> > >>>>> > I've experimented with building asp.net tables dynamically, but I'd >>>>> > like to be able to get some kind of row-oriented functionality so >>>>> that >>>>> > I can use some type of datagrid. I've also experimented with defining >>>>> > a Line Item class, and dealing with the creation and editing in code, >>>>> > but the only way I could figure that out was to hard-code the >>>>> specific >>>>> > number of areas in the class -- which means I need to modify the code >>>>> > in order to change the number of areas. >>>>> > >>>>> > Can anyone offer a suggestion on how to proceed? All comments >>>>> > gratefully appreciated. >>>>> >>>> >>>> >>> >> >
