тестовая оболочка - это так сложно:)

Язык Visual Basic на платформе .NET.

Модераторы: Ramzes, Sebas

matdilon
Начинающий
Начинающий
 
Сообщения: 12
Зарегистрирован: 10.08.2010 (Вт) 23:20

тестовая оболочка - это так сложно:)

Сообщение matdilon » 17.08.2010 (Вт) 14:46

Делаю тестовую оболочку. На форме размещаю TexBox1 и Button1. В TexBox1 человек будет записывать свой логин,
а затем наживать на Button1. В результате обработки события Button1.Click должен создаваться каталог ADOX
(MS Access.2007) и одноименная таблица для каждого человека. В итоге, сколько человек, столько таблиц.

В предложенном коде: создается каталог ADOX (MSAccess2007) и генерируется таблица с именем для каждого тестируемого.
Когда первый раз написал этот код, то создавался каталог и таблица с заданными полями, а теперь не создается таблица,
не говоря о том, чтобы имени таблицы присваивалось имя человека.
Добавлены через /Меню/ - /Add Reference/- /.NET/ - System.Windows.Forms

Вопросы такие: 1. Почему не создается таблица и 2. Как сделать так, чтобы имя человека из TextBox1 становилось именем таблицы в каталоге MSAccess.


Код: Выделить всё
Imports System.Data.OleDb
Imports System.Windows.Forms


Public Class Form1

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

        Me.Text = "Oracul"
        TextBox1.Clear()
        Button1.Text = "Далее"

        Dim cat As New ADOX.Catalog
        Try
            cat.Create("Provider=Microsoft.ACE.OleDb.12.0; " & _
                             "Data Source=""C:\oracul.accdb""")
        Catch ex As Runtime.InteropServices.COMException
            MessageBox.Show("База данных уже существует")
        Finally

        End Try
    End Sub

    Public Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

        REM нажатие на кнопку происходит каждый раз для идентификации человека и создания одноименной
        REM таблицы с его данными


        Dim CON As New OleDbConnection("Provider=Microsoft.ACE.OleDb.12.0; " & _
                             "Data Source=""C:\oracul.accdb""")

        CON.Open()
        Dim COMMAND As New OleDbCommand("CREATE TABLE member (Questions char(20), object1 char(20), object2 char(20), object3 char(20), " & _
                     "object4 char(20), object5 char(20), object6 char(20), object7 char(20), object8 char(20)) WHERE member.Text = TextBox1.Text", CON)

        Try
            COMMAND.ExecuteNonQuery()
            MessageBox.Show("Done")

        Catch ex As Exception
            MessageBox.Show("Таблица не создана")

        End Try
        CON.Close()

    End Sub
End Class

Samsonov
Новичок
Новичок
 
Сообщения: 30
Зарегистрирован: 22.04.2010 (Чт) 7:32
Откуда: DC

Re: тестовая оболочка - это так сложно:)

Сообщение Samsonov » 17.08.2010 (Вт) 16:50

matdilon писал(а):Почему не создается таблица?
Код: Выделить всё
CREATE TABLE member (…) WHERE member.Text = TextBox1.Text
А чо, так можно, да? :shock: :roll: :?

Как сделать, чтобы имя человека из TextBox1 становилось именем таблицы?
Я бы попробовал так:
Код: Выделить всё
Dim COMMAND As New OleDbCommand("CREATE TABLE " & TextBox1.Text & " (Questions char(20), … object8 char(20))", CON)
Конечно, неплохо бы ещё навесить защиту от дурака, чтобы некорректные имена таблиц не вводили.

matdilon
Начинающий
Начинающий
 
Сообщения: 12
Зарегистрирован: 10.08.2010 (Вт) 23:20

Re: тестовая оболочка - это так сложно:)

Сообщение matdilon » 17.08.2010 (Вт) 17:46

Samsonov, Огромное спасибо! Надеюсь на помощь при последующих вопросах. :) :alien:

Joo
Постоялец
Постоялец
Аватара пользователя
 
Сообщения: 762
Зарегистрирован: 14.08.2008 (Чт) 11:55
Откуда: Казахстан

Re: тестовая оболочка - это так сложно:)

Сообщение Joo » 19.08.2010 (Чт) 5:56

Что за бред? Нафига плодить таблицы?
"Им будет не просто, тем кто полагается на истину авторитета, вместо того чтобы полагаться на авторитет Истины"
Джеральд Месси, Египтолог

Samsonov
Новичок
Новичок
 
Сообщения: 30
Зарегистрирован: 22.04.2010 (Чт) 7:32
Откуда: DC

Re: тестовая оболочка - это так сложно:)

Сообщение Samsonov » 21.08.2010 (Сб) 17:47

Joo писал(а):Что за бред? Нафига плодить таблицы?
Создавать отдельные таблицы под каждого пользователя — не такой уж и бред, если единственным потребителем информации из этих таблиц будет тот самый пользователь.

Вот если информация предназначена для произвольного круга лиц, и им требуется сводный поток данных от всех источников, — как это обычно бывает в публичных информационных системах, — тогда да, не имеет смысла создавать отдельные таблицы, а вполне достаточно добавить столбец с идентификатором владельца.

Но что получается, если никто кроме самого владельца информации не должен иметь к ней доступа?
  • К каждой строке добавляется «совершенно лишний» столбец.
  • Если необходимо обеспечить уникальность значений некоторых столбцов, но только в рамках каждого пользователя (то есть у разных пользователей могут встречаться записи с одинаковыми значениями), мы должны вместо простых индексов использовать составные.
  • Независимо от предыдущего пункта, мы должны использовать составные индексы для каждой комбинации поисковых критериев. Даже если нам нужно просто выбрать все записи одного пользователя без сортировки, нам уже нужен индекс по его идентификатору.
И чем больше пользователей, чем больше данных хранит каждый из них, тем всё больше вычислительных мощностей расходуется впустую — по сравнению с тем, когда идентификатор владельца закодирован в имени таблицы.


А ещё, если база управляется серверной СУБД, раздельные таблицы позволяют организовать ограничение доступа к данным на уровне учётных записей СУБД.


Другое дело, что для автора топика с его списком студентов такие навороты действительно могут быть излишни.

Joo
Постоялец
Постоялец
Аватара пользователя
 
Сообщения: 762
Зарегистрирован: 14.08.2008 (Чт) 11:55
Откуда: Казахстан

Re: тестовая оболочка - это так сложно:)

Сообщение Joo » 22.08.2010 (Вс) 15:06

Samsonov писал(а):Создавать отдельные таблицы под каждого пользователя — не такой уж и бред, если единственным потребителем информации из этих таблиц будет тот самый пользователь.

Это крайне не верный подход к проектированию БД. Во время эксплуатации системы, кол-во таблиц должно быть четко определено, и не может меняться.
Я даже представить себе пока такую систему не могу, где такой подход был бы оправдан.
Например создавая тестовую систему для учебного заведения, где каждый год добавляется не одна сотня новых студентов, что может получиться?
Samsonov писал(а):И чем больше пользователей, чем больше данных хранит каждый из них, тем всё больше вычислительных мощностей расходуется впустую — по сравнению с тем, когда идентификатор владельца закодирован в имени таблицы.

В МАЛЕНБКОМ!!! вузе порядка 2000 студентов. Вы предлагаете завести 2000 таблиц? И каждый год наращивать по ~400 таблиц? Вы считаете так лучше? Что за бред?
"Им будет не просто, тем кто полагается на истину авторитета, вместо того чтобы полагаться на авторитет Истины"
Джеральд Месси, Египтолог

iGrok
Артефакт VBStreets
Артефакт VBStreets
 
Сообщения: 4272
Зарегистрирован: 10.05.2007 (Чт) 16:11
Откуда: Сетевое сознание

Re: тестовая оболочка - это так сложно:)

Сообщение iGrok » 22.08.2010 (Вс) 15:30

Joo писал(а):Во время эксплуатации системы, кол-во таблиц должно быть четко определено, и не может меняться.

Пример - отдельная табличка под подробную ежедневную статистику. Если объекты ведения статистики сильно различаются - то кол-во таких табличек = кол-ву объектов ведения статистики * кол-во дней, за которые хранится информация.
Вся "краткая" статистика по всем объектам, доступ к которой нужен постоянно, разумеется, в единой общей табличке.

Пример, конечно, не соответствует тематике топика, но призван несколько облегчить твой пыл, и пояснить, что эта твоя фраза несколько далека от истины.
label:
cli
jmp label

Samsonov
Новичок
Новичок
 
Сообщения: 30
Зарегистрирован: 22.04.2010 (Чт) 7:32
Откуда: DC

Re: тестовая оболочка - это так сложно:)

Сообщение Samsonov » 22.08.2010 (Вс) 19:59

Joo писал(а):Вы предлагаете завести 2000 таблиц под каждого студента, и каждый год наращивать по ~400 таблиц?
Кто сказал, что «пользователь» — это студент? Пользователем в данном случае должен быть факультет (деканат факультета), а факультетов в обычном институте не более полудюжины — даже в МГУ их всего 40 штук, но никак не сотни и тысячи.

Во время эксплуатации системы, кол-во таблиц должно быть чётко определено, и не может меняться.
// Разработчики и применители метода CREATE TEMPORARY TABLE тихо посмеиваются…

Я даже представить себе пока такую систему не могу, где такой подход был бы оправдан.
Ограниченность кругозора — ещё не повод считать бредом всё, что в него не вписывается.

Например, представьте себе базу данных, в которой разные компании хранят инвентарный список своих активов с дислокацией по филиалам — всякое компьютерное оборудование, прочая техника и т. п. — а система, помимо справочных данных, периодически выдаёт им расчёт стоимости обслуживания этой техники в будущем году. Некоторые таблицы этой БД являются общими для всех пользователей, и править их может только администратор. Помимо них, у каждого пользователя есть свой набор таблиц, к которому только он имеет доступ и в котором обеспечивается нужная уникальность данных, — список филиалов, типовые комплекты оборудования, их расстановка по филиалам, квалификация обслуживающего персонала, тарифные ставки в каждом регионе. Отчёты выдаются тоже только самому пользователю, владеющему данными, и никому другому.

Как по-вашему, что бы выиграла такая система от размещения всех данных в едином наборе таблиц? Она бы только потеряла много места и производительности, потому что счёт записей идёт на сотни тысяч для каждого пользователя, тогда как самих пользователей не более 20 штук. Да и защита доступа к данным на уровне учётных записей СУБД — тоже не лишняя штука.

iGrok
Артефакт VBStreets
Артефакт VBStreets
 
Сообщения: 4272
Зарегистрирован: 10.05.2007 (Чт) 16:11
Откуда: Сетевое сознание

Re: тестовая оболочка - это так сложно:)

Сообщение iGrok » 22.08.2010 (Вс) 20:38

Samsonov писал(а):Кто сказал, что «пользователь» — это студент?

Топикстартер. Сказал, что пользователь - тестируемый.

Cоздавать 2000 таблиц для 2000 пользователей - это уже бред. Да даже 200 таблиц на 200 юзеров - бред. А уж 10 таблиц на 10 юзеров - бред ещё бОльший.

Т.е. таблица на каждого тестируемого - точно бред.
Можно создавать таблицы на тесты, отделы, факультеты, или ещё какие-то группы, на которые тестируемые(или результаты тестов) натурально подразделяются.
label:
cli
jmp label

Joo
Постоялец
Постоялец
Аватара пользователя
 
Сообщения: 762
Зарегистрирован: 14.08.2008 (Чт) 11:55
Откуда: Казахстан

Re: тестовая оболочка - это так сложно:)

Сообщение Joo » 23.08.2010 (Пн) 6:01

Samsonov писал(а):Кто сказал, что «пользователь» — это студент?

iGrok писал(а):Топикстартер. Сказал, что пользователь - тестируемый.

Раз подтверждение, но пускай и не явно студент, но ТЕСТИРУЕМЫЙ, а проверка знаний методом тестирования, рассчитана на поток, а значит на большое кол-во человек.
Samsonov писал(а):Другое дело, что для автора топика с его списком студентов

А вот подтверждение из Ваших уст, ты сам решил, что это студенты.
iGrok писал(а):Пример - отдельная табличка под подробную ежедневную статистику. Если объекты ведения статистики сильно различаются - то кол-во таких табличек = кол-ву объектов ведения статистики * кол-во дней, за которые хранится информация.

Вполне в данном случае оправдано создать кол-во таблиц равным объектам статистики + в каждую добавить поле с датой.
Я думаю структура объекта статистики не меняется изо дня в день, ну уж если меняется, то действительно от создания отдельной таблицы под каждый случай не избежать, но и тут кол-во таблиц конечно которое равно кол-ву объектов * кол-во дней, т.е. на этапе разработки их можно посчитать и определить.
Samsonov писал(а):Например, представьте себе базу данных, в которой разные компании хранят инвентарный список своих активов с дислокацией по филиалам — всякое компьютерное оборудование, прочая техника и т. п. — а система, помимо справочных данных, периодически выдаёт им расчёт стоимости обслуживания этой техники в будущем году. Некоторые таблицы этой БД являются общими для всех пользователей, и править их может только администратор. Помимо них, у каждого пользователя есть свой набор таблиц, к которому только он имеет доступ и в котором обеспечивается нужная уникальность данных, — список филиалов, типовые комплекты оборудования, их расстановка по филиалам, квалификация обслуживающего персонала, тарифные ставки в каждом регионе. Отчёты выдаются тоже только самому пользователю, владеющему данными, и никому другому.

Тут ключевой момент Разные компании. Для каждой компании следует завести отдельную БД!!! под её нужды + центральную БД для общих нужд.
Samsonov писал(а):Разработчики и применители метода CREATE TEMPORARY TABLE тихо посмеиваются…

Это то тут при чем??? Разве разговор шел о временных таблицах??? Я по моему имел ввиду кол-во реальных таблиц, кои Вы и предлагаете создавать под каждого пользователя.
Samsonov писал(а):Ограниченность кругозора — ещё не повод считать бредом всё, что в него не вписывается.

Ваш пример не убедил. Типичная ошибка при проектировании БД, студента первокурсника.

Покажите мне реальный пример системы, где такой подход действительно оправдан.
"Им будет не просто, тем кто полагается на истину авторитета, вместо того чтобы полагаться на авторитет Истины"
Джеральд Месси, Египтолог

iGrok
Артефакт VBStreets
Артефакт VBStreets
 
Сообщения: 4272
Зарегистрирован: 10.05.2007 (Чт) 16:11
Откуда: Сетевое сознание

Re: тестовая оболочка - это так сложно:)

Сообщение iGrok » 23.08.2010 (Пн) 11:57

Joo писал(а):Вполне в данном случае оправдано создать кол-во таблиц равным объектам статистики + в каждую добавить поле с датой.
Я думаю структура объекта статистики не меняется изо дня в день, ну уж если меняется, то действительно от создания отдельной таблицы под каждый случай не избежать, но и тут кол-во таблиц конечно которое равно кол-ву объектов * кол-во дней, т.е. на этапе разработки их можно посчитать и определить.

Структура-то не меняется. Вот только в табличке по одному объекту - 10 млн записей в день, а по другому - ещё 5 млн. Объём представляешь? Причём первая - вообще без индексов. Т.к. информация по нему, в отличие от второго, может понадобиться только в очень крайнем случае, а с нужными индексами она из 3 гигов разрастается до 4 с мелочью.

Да, кол-во объектов на этапе разработки может быть и неизвестно. Например, подробный лог с установленных датчиков. Кол-во датчиков может варьироваться. Кол-во дней, которые информация будет храниться - тоже неизвестно, и может задаваться индивидуально для каждого датчика в зависимости от важности того, чего он там показывает.
label:
cli
jmp label

Joo
Постоялец
Постоялец
Аватара пользователя
 
Сообщения: 762
Зарегистрирован: 14.08.2008 (Чт) 11:55
Откуда: Казахстан

Re: тестовая оболочка - это так сложно:)

Сообщение Joo » 23.08.2010 (Пн) 14:17

iGrok писал(а):Структура-то не меняется. Вот только в табличке по одному объекту - 10 млн записей в день, а по другому - ещё 5 млн. Объём представляешь? Причём первая - вообще без индексов. Т.к. информация по нему, в отличие от второго, может понадобиться только в очень крайнем случае, а с нужными индексами она из 3 гигов разрастается до 4 с мелочью.

Ну от того, что Вы разобъете по таблице на каждый день, объем (на диске) не уменьшится. Так? Так, ну или не существенно, с учетом добавление дополнительного поля.
Второе, для упрощения обработки, так-как информация может и не понадобиться, хорошо сделать ежедневное архивное(возможно со сжатьием) копирование(тогда не нужно заводить отдельное поле с датой (вот вам и экономия и фиксированная структура БД), этим Вы получите более компактную БД, если нужно просмотреть статистику за определенный день, достаточно восстановить резервную копию за нужный день. Архивные копии старше даты, после которой информация становится не нужной, стоит удалить. Так Вам не нужно заводить отдельную таблицу на каждый день.
iGrok писал(а):Да, кол-во объектов на этапе разработки может быть и неизвестно. Например, подробный лог с установленных датчиков. Кол-во датчиков может варьироваться. Кол-во дней, которые информация будет храниться - тоже неизвестно, и может задаваться индивидуально для каждого датчика в зависимости от важности того, чего он там показывает.

Если структура у датчиков одинаковая, то статистику с них можно хранить в одной таблице (добавить поле имя датчика(вернее его ID). Если добавляется датчик с новой структурой, то всяко придеться прибегать к разработке.
Вы говорите о больших объемах, во первых миллионы записей это не так страшно для хорошой СУБД и нормального сервера, это не аргумент, во вторых когда будут действительно большой объем информации то будет необходимо задуматься о распределенной СУБД.
"Им будет не просто, тем кто полагается на истину авторитета, вместо того чтобы полагаться на авторитет Истины"
Джеральд Месси, Египтолог

iGrok
Артефакт VBStreets
Артефакт VBStreets
 
Сообщения: 4272
Зарегистрирован: 10.05.2007 (Чт) 16:11
Откуда: Сетевое сознание

Re: тестовая оболочка - это так сложно:)

Сообщение iGrok » 23.08.2010 (Пн) 18:32

Оно и так всё архивируется каждый день, архивы хранятся существенно дольше, около пары лет.
И объём от поля не увеличится, т.к. там и так есть это поле с таймстампом.
Данные пишутся непрерывно, быстро слить старую таблицу в архив и очистить её - можно, но это ведёт к существенному усложнению системы. Просто вычислять имя таблички в зависимости от текущей даты - гораздо проще.
Статистика за предыдущие 60-90 дней требуется постоянно, поэтому сливать её в архив и удалять из базы нет смысла.
Если просто удалять старые записи из общей таблицы - это приведёт к сильной фрагментации таблицы. Делать переупаковку пары гигабайт данных - увольте. У нас, конечно, мощные серверы(относительно, разумеется), но грузить их бессмысленной работой - не стоит.

Структура не совсем одинаковая. У нас записи с разных объектов имеют разный физ. смысл. Если они будут валяться в одной таблице - это просто приведёт к увеличению нагрузки на базу при выборке. Тем более, постоянно требуются только те данные, которых меньше (5млн). Поэтому на большой табличке и не стоят индексы.

Распределённой субд пока не надо, хватает и того, что есть. Но я не об этом - я пытаюсь объяснить, что в данном случае нет абсолютно никакого резона паковать всё в одну табличку, кроме "а мне так захотелось".
label:
cli
jmp label

Joo
Постоялец
Постоялец
Аватара пользователя
 
Сообщения: 762
Зарегистрирован: 14.08.2008 (Чт) 11:55
Откуда: Казахстан

Re: тестовая оболочка - это так сложно:)

Сообщение Joo » 24.08.2010 (Вт) 7:06

iGrok писал(а):Делать переупаковку пары гигабайт данных

Я написал, что возможно со сжатием, но не обязательно.
iGrok писал(а):Просто вычислять имя таблички в зависимости от текущей даты - гораздо проще.

Проще приконнектиться к БД, и нечего не вычислять.
iGrok писал(а):Данные пишутся непрерывно, быстро слить старую таблицу в архив и очистить её - можно, но это ведёт к существенному усложнению системы.
Если просто удалять старые записи из общей таблицы - это приведёт к сильной фрагментации таблицы.

Конечно можно, но система не чуть не усложнится. Если Вы делаете копию без сжатия, элементарно создаете новую БД на основе подготовленной шаблонной базы(зачем очищать, когда можно приготовить чистую болванку), и меняете коннект на неё.
iGrok писал(а):Если они будут валяться в одной таблице - это просто приведёт к увеличению нагрузки на базу при выборке.

Вы постоянно ставите, как аргумент кол-во записей, Вы знаете возможности своей СУБД? Например, не самая мощная, всем известная СУБД MySQL, таблицы myisam, лимит записей 4 миллиарда!!! Т.е. это говорит о том, что если БД умеет полноценно работать с таким кол-вом записей, значит Ваши 5 миллионов * десяток датчиков она обработает на раз. А если взять MS SQL или Oracle? А, грамотная простановка индексов, позволит Вам значительно снизить нагрузку при выборке.

Как я уже говори во время эксплуатации БД, кол-во таблиц и их структура должно быть четко определено. Конечно, может быть исключение. если Вы создаете редактор баз данных ;-)

У всех Ваших проблем, один корень - это неверное проектирование системы в целом!
Мне так не кто и не привел, весомый аргумент в пользу такого, генерирование N-го кол-ва таблиц, способа организации базы данных. Ваши "миллионы записей" и "нагрузка при выборке" не в счет, так-как это решается путем оптимизации, и приведению БД к нормальной форме (как минимум 3й( Бойса-Кодда).

Дальше, думаю, обсуждать нет смысла, так-как тема превратиться в многократное пережевывание вышесказанного, хотя можно часть этой темы перенести в треп, и там пофлудить.
"Им будет не просто, тем кто полагается на истину авторитета, вместо того чтобы полагаться на авторитет Истины"
Джеральд Месси, Египтолог

iGrok
Артефакт VBStreets
Артефакт VBStreets
 
Сообщения: 4272
Зарегистрирован: 10.05.2007 (Чт) 16:11
Откуда: Сетевое сознание

Re: тестовая оболочка - это так сложно:)

Сообщение iGrok » 24.08.2010 (Вт) 14:19

Мда. Если без сжатия - читайте выше - будет сильная фрагментация таблиц. А это никогда положительно не сказывалось на производительности. :roll:

Joo писал(а):новую БД

Эээ.. С дуба рухнули? :shock: (других слов подобрать как-то не получилось)
Из-за одной таблицы переливать ВСЮ бд?
Там эти таблички - это так, дневная статистика, которую и потерять-то не страшно в принципе. Ну плохо, конечно, но не смертельно.

Лимит-то, может, и 4 миллиарда, но видимо возможности и особенности работы мускуловских движков бд (в данном случае, InnoDB) Вы себе представляете не очень хорошо. MyISAM, конечно, потянет 4kkk записей в виде лога, но вот активная работа с ними - это миф. Если ещё и вспомнить про блокировку на уровне таблицы целиком, а не отдельных записей... InnoDB потянет и больше 4kkk, но опять же, активно работать с таким объёмом - то ещё удовольствие.
У нас, конечно, не 4kkk. Но (5kk + 10kk) * 90 = 1.3kkk. Для мускула это вполне себе серьёзная цифра. Особенно если учесть, что 5 + 10 - это "среднегодовые". Обычно получается где-то 6-8 + 20-25, ну и в пике до 10 + 40. А это уже 4.5kkk

Активная работа с таблицами с таким кол-вом записей? Да ладно. ) Там один индекс полгига будет весить.
Причём реально постоянно оттуда нужны только данные за текущий и предыдущий дни. Причём по-отдельности. И на кой чёрт в данном случае усложнять условия выборки и забивать кеш бд лишними данными (индекс-то целиком поднимается) я абсолютно не понимаю.

Да, данные за текущий день дёргаются примерно 300-500 раз в секунду. За предыдущий - пару тысяч раз в день.
Да, надо не забыть, что всё это чудо - ОДИН веб-сервис. Соответственно, там, конечно, не домашние машинки, но и не кластер.
Да, я не спорю, всю систему можно спроектировать и по-другому. Вот только это не упростит её, а усложнит. Увеличит объёмы чисто сервисных операций. И на кой это надо?

Joo писал(а):Мне так не кто и не привел, весомый аргумент в пользу такого, генерирование N-го кол-ва таблиц, способа организации базы данных.

А мне так никто и не привёл весомого аргумента в пользу любого другого способа организации данных. И что? Пат? :lol:
label:
cli
jmp label

Joo
Постоялец
Постоялец
Аватара пользователя
 
Сообщения: 762
Зарегистрирован: 14.08.2008 (Чт) 11:55
Откуда: Казахстан

Re: тестовая оболочка - это так сложно:)

Сообщение Joo » 24.08.2010 (Вт) 14:30

iGrok писал(а):Из-за одной таблицы переливать ВСЮ бд?

Какого праздника её нужно переливать???? Я по моему не предлагал переливать БД.
......
iGrok писал(а):А мне так никто и не привёл весомого аргумента в пользу любого другого способа организации данных. И что? Пат?

Готов обсуждать дальше, только не в этой теме =) А то бан схлопочем )))
"Им будет не просто, тем кто полагается на истину авторитета, вместо того чтобы полагаться на авторитет Истины"
Джеральд Месси, Египтолог

iGrok
Артефакт VBStreets
Артефакт VBStreets
 
Сообщения: 4272
Зарегистрирован: 10.05.2007 (Чт) 16:11
Откуда: Сетевое сознание

Re: тестовая оболочка - это так сложно:)

Сообщение iGrok » 24.08.2010 (Вт) 14:55

Может быть, я неправильно понял смысл вот этого:
Joo писал(а):элементарно создаете новую БД на основе подготовленной шаблонной базы

:?:

Не, ну пообсуждать-то мы можем и в личке, там точно никто никаких банов не раздаёт. =)
label:
cli
jmp label

matdilon
Начинающий
Начинающий
 
Сообщения: 12
Зарегистрирован: 10.08.2010 (Вт) 23:20

Re: тестовая оболочка - это так сложно:)

Сообщение matdilon » 29.08.2010 (Вс) 22:31

Joo писал(а):Что за бред? Нафига плодить таблицы?


Именно так, это оправдано на 100% - я же говорил, что это тестовая оболочка. Нужно собирать дарнные, например, на выборке 35 чел. Для каждого нужно создать отдельную ячейку, или поле в БД или столбик в Excel.

FireFenix
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1640
Зарегистрирован: 25.05.2007 (Пт) 10:24
Откуда: Mugen no Sora

Re: тестовая оболочка - это так сложно:)

Сообщение FireFenix » 29.08.2010 (Вс) 23:04

matdilon писал(а):
Joo писал(а):Что за бред? Нафига плодить таблицы?


Именно так, это оправдано на 100% - я же говорил, что это тестовая оболочка. Нужно собирать дарнные, например, на выборке 35 чел. Для каждого нужно создать отдельную ячейку, или поле в БД или столбик в Excel.

Бред, таблицы должны быть максимально статичными
Птицей Гермеса меня называют, свои крылья пожирая... сам себя я укрощаю
私はヘルメスの鳥 私は自らの羽根を喰らい 飼い慣らされる

matdilon
Начинающий
Начинающий
 
Сообщения: 12
Зарегистрирован: 10.08.2010 (Вт) 23:20

Re: тестовая оболочка - это так сложно:)

Сообщение matdilon » 12.09.2010 (Вс) 19:27

Постарался учесть предыдущие ошибки. Например, не создавать в базе данных для каждого
тестируемого отдельное поле.

Цель: Создание тестовой оболочки.
Прежде всего, тестируемый должен ввести свой логин в TextBox1, и нажав Button1 вписать
себя в базу данных. Для этого предполагается создать таблицу "data" и поле "members" в нем для списка тестируемых.
Эти таблица и поле создаются в уже существующем файле (.accdb)
В другой таблице "variables" в поле "vars", этого же файла, записаны вопросы для тестирования.
Предполагается читать эти вопросы по очереди и выводить их на Label1.
ДАлее, с помощью инструментов - RadioButtons оценивать эти вопросы и по каждому нажатию Form2.Button1,
отправлять эти данные в таблицу "data".

Задам пока самые важные вопросы:
1. Возможно ли чтобы, в зависимости от изначального количества вопросов в таблице "variables"
было программно создано такое же количество полей-вопросов в таблице данных ("data") Или количество полей
должно быть жестко статично (задано заранее)?
Это бы значительно упростило использование программы.
2. Как читать вопросы в Label1 не все сразу, а построчно - Label1.Text = myReader.GetString(0)???
3. И совсем мало представления как нужно прописать код для RadioButtons, чтобы потом по запросу записывать
данные в базу. После каждого RadioButtons.IsChecked ожидается переход к следующему вопросу.

http://www.megaupload.com/?d=5A3TKE8I - здесь весь проект

Код: Выделить всё
Imports System.Data.OleDb
Imports System.Windows.Forms
Imports System.IO


Public Class Form2
    Friend TextBox1 = Form1.TextBox1

    Dim n As Integer
    Private Sub Form2_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Label1.Text = Nothing
        RadioButton1.Text = "1" : RadioButton2.Text = "2" : RadioButton3.Text = "3" : RadioButton4.Text = "4"
        RadioButton5.Text = "5" : RadioButton6.Text = "6" : RadioButton7.Text = "7"
        Button1.Text = "Далее"

        Dim con As New OleDb.OleDbConnection
        con.ConnectionString = "Provider=Microsoft.ACE.OleDb.12.0; Data Source=C:\DB_organon.accdb"
        con.Open()
        If con.State <> ConnectionState.Open Then MessageBox.Show("Not connected")
        Dim quer As String = "SELECT variables.vars FROM variables"
        Dim myCommand As New OleDb.OleDbCommand(quer, con)
        Dim myReader As OleDb.OleDbDataReader = myCommand.ExecuteReader()

        While myReader.Read()
            Label1.Text = myReader.GetString(0)
        End While
        n = 0

    End Sub
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim con As New OleDbConnection("Provider=Microsoft.ACE.OleDb.12.0; Data Source=C:\DB_organon.accdb")
        con.Open()
        Dim quer As String = "SELECT variables.vars FROM variables"
        Dim myCommand As New OleDb.OleDbCommand(quer, con)
        Dim myReader As OleDbDataReader = myCommand.ExecuteReader()
        While myReader.Read()
            Label1.Text = myReader.GetString(0)
        End While
        n = 0

        If RadioButton1.Checked = True Then
            Label1.Text = myReader.GetString(0)
            Dim myCommand2 As New OleDbCommand("ALTER TABLE Data add column (...), con")
            n = n + 1

            If myReader Is Nothing Then
                MessageBox.Show("Тестирование окончено")
                Me.Close()
            End If
        End If

    End Sub
End Class

FireFenix
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1640
Зарегистрирован: 25.05.2007 (Пт) 10:24
Откуда: Mugen no Sora

Re: тестовая оболочка - это так сложно:)

Сообщение FireFenix » 13.09.2010 (Пн) 12:00

matdilon писал(а):1. Возможно ли чтобы, в зависимости от изначального количества вопросов в таблице "variables"
было программно создано такое же количество полей-вопросов в таблице данных ("data") Или количество полей
должно быть жестко статично (задано заранее)?

Ты что-то недоперекурил

questions (id, text, id_answer)
answers (id, id_question, text)

Код: Выделить всё
SELECT * FROM questions;
SELECT * FROM answers WHERE id_question='" & Id & "'


matdilon писал(а):2. Как читать вопросы в Label1 не все сразу, а построчно - Label1.Text = myReader.GetString(0)???

Курите мсдн, там всё доходчиво с примерами есть!!!! http://msdn.microsoft.com/ru-ru/library ... 00%29.aspx

OleDbDataReader - Объект который получает последовательно результаты запроса, которые есть таблица
OleDbDataReader.GetType(id) - получает значение (столбца = id) указанного типа из кортежа в текущей позиции (изначально = -1)
OleDbDataReader.Read - переход к следующему кортежу

matdilon писал(а):3. И совсем мало представления как нужно прописать код для RadioButtons, чтобы потом по запросу записывать
данные в базу. После каждого RadioButtons.IsChecked ожидается переход к следующему вопросу.

Изучайте язык программирования

Ответы из БД -> Массив кнопок -> Нажатие кнопки далее -> Id нажатой кнопки массива -> сопоставлением с Id ответа -> Обновление/Добавление в БД

Предвидение mode on:
Для получения перемешанного списка вопросов
Код: Выделить всё
SELECT * FROM table ORDER BY NEWID();
Последний раз редактировалось FireFenix 13.09.2010 (Пн) 14:03, всего редактировалось 1 раз.
Птицей Гермеса меня называют, свои крылья пожирая... сам себя я укрощаю
私はヘルメスの鳥 私は自らの羽根を喰らい 飼い慣らされる

Joo
Постоялец
Постоялец
Аватара пользователя
 
Сообщения: 762
Зарегистрирован: 14.08.2008 (Чт) 11:55
Откуда: Казахстан

Re: тестовая оболочка - это так сложно:)

Сообщение Joo » 13.09.2010 (Пн) 13:52

FireFenix писал(а):questions (id, text, id_answer)
answers (id, id_question, text)

Это еще что такое??? Вот:
questions(id,text)
"Им будет не просто, тем кто полагается на истину авторитета, вместо того чтобы полагаться на авторитет Истины"
Джеральд Месси, Египтолог

FireFenix
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1640
Зарегистрирован: 25.05.2007 (Пт) 10:24
Откуда: Mugen no Sora

Re: тестовая оболочка - это так сложно:)

Сообщение FireFenix » 13.09.2010 (Пн) 14:02

Joo писал(а):
FireFenix писал(а):questions (id, text, id_answer)
answers (id, id_question, text)

Это еще что такое??? Вот:
questions(id,text)

а правильный ответ?
Птицей Гермеса меня называют, свои крылья пожирая... сам себя я укрощаю
私はヘルメスの鳥 私は自らの羽根を喰らい 飼い慣らされる

Joo
Постоялец
Постоялец
Аватара пользователя
 
Сообщения: 762
Зарегистрирован: 14.08.2008 (Чт) 11:55
Откуда: Казахстан

Re: тестовая оболочка - это так сложно:)

Сообщение Joo » 13.09.2010 (Пн) 16:56

FireFenix писал(а):а правильный ответ?

Лоханулся я, ну ты бы хоть тогда поле создал с более говорящим названием 'trueAnswerId' :-)
"Им будет не просто, тем кто полагается на истину авторитета, вместо того чтобы полагаться на авторитет Истины"
Джеральд Месси, Египтолог

netdemon
Продвинутый пользователь
Продвинутый пользователь
Аватара пользователя
 
Сообщения: 179
Зарегистрирован: 04.09.2007 (Вт) 15:51

Re: тестовая оболочка - это так сложно:)

Сообщение netdemon » 25.06.2011 (Сб) 16:30

Используйте реляционную структуру. Таблица пользователи связанная с таблицами тесты, тосты, просто и т.д. связью один ко многим с параметром сохранения целостности и каскадным обновлением записей. также связи могут быть прямые, кривые, кольцевые, реверсивные и т.д. Купите книжку по MS Acces для чайников и юзайте. :D. Можно даже не использовать VB для этого - Вам поможет VBA. Задать все необходимые параметры, права доступа и т.д. Потом сделать копию и скомпилировать в приложение БД. И пользовать с удовольствием.

P.S если нужна оболочка для тестов-пиши ТЗ мне на мыло. О цене договоримся.
Лишь разум потерянный бесповоротно мною. Наполнить может сердце мне тоской.
Нельзя обнять необъятное и впихнуть невпихуемое.

netdemon
Продвинутый пользователь
Продвинутый пользователь
Аватара пользователя
 
Сообщения: 179
Зарегистрирован: 04.09.2007 (Вт) 15:51

Re: тестовая оболочка - это так сложно:)

Сообщение netdemon » 22.07.2011 (Пт) 18:27

И тишина. Походу чел купил книжку и зачитывается в захлёб. Или мозг взорвался. :roll:
Лишь разум потерянный бесповоротно мною. Наполнить может сердце мне тоской.
Нельзя обнять необъятное и впихнуть невпихуемое.


Вернуться в Visual Basic .NET

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 29

    TopList