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. >>>> >>> >>> >> >
