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

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

что ваш опыт говорит на эту тему?

что ваш опыт говорит на эту тему?

------

По умолчанию: таблица идет с суррогатным первичным ключом.

Мало того, имена первичных ключей, имена вторичных ключей и типы данных для ключей - регламентированы.

Отсутствие ключа или другие несоответствия - оговаривается дополнительно.

Код пишется под заданную ключами структуру.

Пользовательские поля - отдельно.

городить лишние поля, понимаю, плохой стиль

-----

???

Плохой стиль - это когда надо думать как апдейтнуть запись которая без ключа.

Плохой стиль - это когда надо думать как апдейтнуть запись которая без ключа.

а что толку, если мы имеем такой "ключ", который называется ID, и значений которого нигде кроме этой таблицы не встречается? если уж ключ, так мы должны как-то снаружи таблицы его иметь возможность иметь/получить, иначе какой в нем толк? в моем примере это могло бы быть сочетание датапоездки+автомобиль/водитель+индекспоездки (если предположить, что водитель развозит, например, пиццу, и делает несколько поездок в день. тогда мы знаем дату, водителя (или транспорт), а индексы будем просто перебирать подряд, пока не обнаружим, что запись отсутствует. в таком ключе была бы польза, а просто индекс, которого мы не знаем - не понимаю. или иметь не по одной записи на поездку в таблице, а по одной записи на список поездок за день, тогда и индекс отпадает.

Пару раз натыкался на проблемы с композитными ID-ключами (hibernate, doctrine). С тех пор всегда делаю для таблицы ID.

Мой опыт говорит всегда использовать ID в таблицах. Исключение - таблицы для one-to-many или many-to-many отношений.

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

2. "принцип однообразия" (least astonishment) - позовляет хотя бы частично автоматизировать операции с БД

3. разделение между техническим (ID) и логическим (водитель-машина-время) ключом. Логический меняется чаще.

4. ну и скорость / удобство. В MsSQL замена композитного ключа из 7! полей на ID (int) ускорило один сложный select примерно в 20 раз. Вместо 2 минут стал за 5-7 секунд отрабатывать. Писать join-ы тоже попроще становится, да.

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

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

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

Плохой стиль - это когда надо думать как апдейтнуть запись которая без ключа.

В принципе да.

Но если база не особо-большая, то вполне можно обойтис и без ID.

К примеру, если в парке все машины имеют какой-нибудь индивидуальный номер,

к примеру из техпаспорта.

То можно в принципе этим номером и пользоваться.

Только вот проблемка возникает (это для информации ТС).

Если ID может быть 3 - 4 значная,

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

Так же как ключь (ID) можно использовать и комбинацию из нескольких полей,

но это вообще геммморой получится.

Так что лучше использовать ID в каждой таблице.

Это упрощает работу и как уже выше Murr сообщил, без ID это плохой стиль.

Вообще, оптимальный вариант, это когда БД соответствует третьей нормальной форме.

ID нужны для связи таблиц по foreign key и генерируются базой на лету (или еще как-то). Никаким водителям их раздавать не надо - поиск так и идет по номеру.

вернусь к моему примеру. для меня в таблице поездок поле ID было бы оправданно в единственном случае, если мы не можем исключить, что захотим иметь таблицу, куда захотим внести ссылку на поездку. во всех остальных случаех этот ID бесполезен. в одном посте на одном из форумов прочел, что человек всегда создает это поле. это имеет то преимущество, что он экономит время на обдумывание решения, нужно оно или нет : )

когда существует связь таблиц - все понятно: в таблице поездок - ID водителя, и по нему быстро ищется водитель в таблице водителей. но если нам нужно найти водителя "снаружи", по фио, то нужно перерыть всю таблицу, причем до конца, а не пока не наткнемся, т.к. ивановиваниваныч может оказаться не уникальным. или должны выучить его ID : )

может оказаться не уникальным. или должны выучить его ID : )

Вы сейчас программную логику обсуждаете?

или всё же ход действий человека, который должен найти этого водилу через программу?

Если первое, то через ID программа найдёт кого угодно.

Если же второе, то человек ищет обычно по дугим критериям,

к примеру по имени или фамилии, или обоим.

ID ему абсолютно не нужны (она используется преимущественно только программой).

Исключение - таблицы для one-to-many или many-to-many отношений.

-----

Есть соответствующие типы реляций - промежуточные таблицы не обязательны.

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

а что толку, если мы имеем такой "ключ", который называется ID, и значений которого нигде кроме этой таблицы не встречается?

-----

И в таблице всего три строки...

если уж ключ, так мы должны как-то снаружи таблицы его иметь возможность иметь/получить, иначе какой в нем толк?

-----

А разве что-то мешает?

в моем примере это могло бы быть сочетание датапоездки+автомобиль/водитель+индекспоездки (если предположить, что водитель развозит, например, пиццу, и делает несколько поездок в день. тогда мы знаем дату, водителя (или транспорт), а индексы будем просто перебирать подряд, пока не обнаружим, что запись отсутствует. в таком ключе была бы польза, а просто индекс, которого мы не знаем - не понимаю. или иметь не по одной записи на поездку в таблице, а по одной записи на список поездок за день, тогда и индекс отпадает.

-----

Водитель - уволился, машину - списали. Соответствующие записи в таблицах Машины и Водители - удалили.

И это... тебя никто не заставляет пользовать индекс для выборки...

Но это придет с опытом.

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

Предположим мы хотим связать водителя с одной машиной. К одной машине могут быть приписано несколько водителей, водитель всегда только к одной машине. Как мы такое в БД представим? В таблице ВОДИТЕЛЬ будет колонка МАШИНА_ID в которой стоит уникальный ID машины. МАШИНА_ID определена в БД как foreign key ссылающийся на MAШИНА.ID с правилом каскадирования "если на ID есть ссылка, запретить удаление записи из МАШИНА" (DELETE RESTRICT). Позволяет нам на уровне БД добиться целостности данных - не полусится удалить машину оставив водителя, который на ней работать должен.

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

1. ID машины = номерной знак. Просто UPDATE в том же DB2 не пройдет - иззя менять ключи, на которые ссылается запись. Меняем все записи в ВОДИТЕЛЬ, которые на нее ссылаются, меняем номер, опять меняем все записи теперь с новым номером.
2. ID машины - технический. int. Просто UPDATE с новым номером. Всё.

который мы можем определить ключом в таблице машин

-----

Термин "сурогатный ключ" тебе что-нибудь говорит?

Я вообще плохо понимаю, как можно интегрированность данных поставить в зависимость от введенных пользователем данных.

машины имеют уникальный номерной знак

-----

В пределах страны, надеюсь... ведь границу на машине никто не пересекает...

К тому же, на моей памяти были разные знаки на одной и той же машине и были одни и те же знаки на разных машинах...

вернусь к моему примеру. для меня в таблице поездок поле ID было бы оправданно в единственном случае, если мы не можем исключить, что захотим иметь таблицу, куда захотим внести ссылку на поездку. во всех остальных случаех этот ID бесполезен.

Не только. Изменять значения записи проще имея технический ID (который просто-напросто никогда не меняется). Хотим в гуях иметь возможность скорректировать время поездки. Как искать запись, которой UPDATE делать?

в одном посте на одном из форумов прочел, что человек всегда создает это поле. это имеет то преимущество, что он экономит время на обдумывание решения, нужно оно или нет : )

И это тоже. Однообразность помогает.

Но если база не особо-большая, то вполне можно обойтис и без ID.

-----

Эээ... А как ты определишь размер базы до того как ее начнут эксплуатировать?

У меня есть небольшая база - содержит информацию для трансляции внешних документов.

Сколько и каких - Я не знал тогда, не знаю сейчас и не буду знать в будущем - мне

просто пришлют файлик и скажут - Ура, у нас НОВЫЙ клиент... и у него новый

формат документа.

НУ напишу Я то что мне надо для обработки нового документа и будет програмка добавлять

что ей надо в базу. Сколько и чего - Я не знаю. И даже когда будет написано - не буду знать.

Вопрос - как мне починить все это после ошибки оператора - ну вбили что-то не туда и теперь

в выходном документе что-то не соответствует. Ничего не падает, ничего не ломается, просто

на выходе - не то.

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

условный ключ - текстовый, длина 4Кб, содержит смесь фрагментов описаний разных используемых

материалов. Ну вот надо найти "не правильную" запись и поправить. Что Я там буду делать без ИД?

ID ему абсолютно не нужны (она используется преимущественно только программой).

-----

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

Бо, это не для него, а для программиста - чтобы не болела голова...

Что Я там буду делать без ИД?

И я про то же.

С ID намного проще.

Я в принципе во всех БД, которые я планирую, всегда в каждой таблице делаю ID.

Даже если и нет особой необходимости, эта колонка облегчает работу.

попалась вот такая интересная читалка:

http://www.agiledata.org/essays/keys.html

ладно, с ID вроде ясно, что ничего не ясно. т.е. нужно смотреть в каждом конкретном случае.

у меня еще есть вопрос (ы) касательно баз данных, попробую их задать прямо в этой ветке, хотя они уже не касаются непосредственно ID. просто не хочу темы плодить.

я в данный момент делаю небольшой проект(ик), и в качестве базы данных использую .NET System.Data.DataSet class. объем данных ожидаю небольшой (?), справляется нормально пока.

но думаю, чем это мне грозит в случае, если данных окажется больше, чем кажется сегодня?

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

https://blog.capterra.com/free-database-software/

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

да, никаким комьюнити показывать что-то не собираюсь и продавать продукт не собираюсь. это я, прочитав такое:

you don’t have to pay for MySQL but that still doesn’t that there’s no price.
The price is stated by GNU license under which MySQL community edition is released meaning that you need to reveal you source code under the same terms and give it to the community.
Be aware of that fact if you plan to use for commercial project.

кто-нибудь имеет опыт работы с простыми бесплатными базами? посоветуйте что-нибудь.

Sqlite можно посмотреть.

посоветуйте что-нибудь.

-----

Какая система? Юникс или Винда?

Для винды не надо думать - Мс СКЛ.

Для юникса - нее знаю...

на самом деле free & simple? может, oracle тогда уже? ibm informix?

нужно что-нибудь бесплатное, легкое и за вечер освояемое.

mysql пока лучше всего подходит, т.к. когда-то уже использовал (более 10 лет уже, правда).

эх, скорее всего на .net system.data.dataset логичнее всего остановиться : (

а такое кто-нибудь использовал?

https://www.valentina-db.com/en/

спрашиваю потому что знаком лично с разработчиками (с Русланом Засухиным - нет).

нужно что-нибудь бесплатное, легкое и за вечер освояемое.

------

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

Остальное... если Винда стоит - большая часть Мс Скл уже установлена... для внутренних нужд.

Остальное - бесплатное, включая Ентерприсе Манагер для управления этим хозяйством.

Насколько тяжелое для машины - фиг его знает - это от машины.

.net system.data.dataset

-----

Это не база.

естьOracle Database XE 11 g Express Edition.

имеет некоторые для меня несущественные ограничения, но вот такое просто любопытно:

Other
Upon 45 days written notice Oracle may audit the use of the program. You agree to cooperate with Oracle's audit and provide reasonable assistance and access to information. You agree that Oracle shall not be responsible for any of your costs incurred in cooperating with the audit.

как они представляют себе этот аудит?

Это оверкилл имхо.

Вообще можете взять любую базу, для которой есть docker image. Запускаете контейнер, ничего инсталлировать не надо.

Что то мне кажется, что будет достаточно и ентого

https://www.codeproject.com/Articles/13854/Using-XML-as-Da...

Sqlite можно посмотреть.

очень интересный вариант.

обещаемые фичи:

Full-featured SQL
Billions and billions of deployments
Single-file database
Public domain source code
All source code in one file (sqlite3.c)
Small footprint
Max DB size: 140 terabytes (247 bytes)
Max row size: 1 gigabyte
Faster than direct file I/O
Aviation-grade quality and testing
Zero-configuration
ACID transactions, even after power loss
Stable, enduring file format
Extensive, detailed documentation
Long-term support

бегло просмотрел, не смог найти, можно ли еще чем-нибудь доступиться к файлам базы в случае надобности, без библиотек самой базы. но это может оказаться и неважным, если библиотеки удобные.

пошел на сайт https://docs.docker.com/get-started/ (вы это имеете ввиду?), там пишут, что для того, чтобы это пользовать (их хэлло уорлд запустить, например), нужно инсталлировать docker : (.

похоже, в этом случае еще и эту технологию нужно будет осваивать?

Эта технология стоит того, чтобы ее освоить.

запомнил. учту. спасибо.

Мы купили

https://www.devart.com/dotconnect/sqlite/editions.html

и к нему бесплатно идет.

https://www.devart.com/entitydeveloper/

Но если нужно меньше 10 таблиц, то можно все бесплатно

Linq2Sql пользоваться довольно удобно.

Ента тулза тоже нравится

https://sqlitestudio.pl/index.rvt

новый вопрос. попробую дальше эксплуатировать нашу "базу данных автобазы".

устроено так, что при вводе новой поездки по номеру машины ищется имеющаяся, а если не находим, создаем новую запись и ее ид заносим в запись поездки. что должно произойти, если при вводе произошла опечатка, и ошибочно была добавлена в базу несуществующая машина? например, вместо имеющегося номера ХХ АА 790 ввели ХХ АА 700? если ничего не предпринимать, то в базе появится несуществующая машина. допустим, кто-то это усек. как теперь выбросить эту машину из базы, при этом перенаправив ссылки на "правильную"?

идеально было бы распознать при вводе подобие ключей и запросить подтверждения, что ключ новый, преложив как альтернативу выбрать из списка похожих. но если ключ - не машина, а водитель, то как найти подобие "иванова ивана ивановича" и "иванова и.и.", "и.и. иванова", "и. ивн" и пр?

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

как теперь выбросить

------

Поменять ссылочный ИД на нужный.

имеют ли "хорошие субд" средства для этого?

------

Разумеется.

У вас в БД имеется три сущности (Entity): машина, поездка и водитель. Я бы посоветовал использовать вам для любой таблицы своё ID, тогда не будет проблем как в вашем случае с машинными номерами. KFZ-Nummer можно завести как unique, чтобы небыло проблем. То есть у вас в БД на каждую сущность должна быть своя таблица. Если у вас отношения (relation) между сущностями n:m ( каждый водитель может ездить на любой машине) то в этом случае нужна дополнительная таблица, где вы эти соотнощения сохронятете (fahrer_id,fahrzeug_id, reise_id ). При неправильном выборе машины , вы можете легко помянять машину, заменив fahrzeug_id на привильный номер.

я правильно вас понял? вы предполагаете, что, вводя "путевку", оператор не может "автоматически" ввести новую машину, водителя и пр.: добавление машин/водителей должны быть отдельными операциями, а при вводе путевок можно только выбрать из списка имеющихся? вроде логично, тогда проблема не возникает.

к сожалению, у меня несколько другая ситуация я свои "путевки" беру пачками из интернета, в различных источниках, и там один источник называет "водителя" "абв.гд", другой - "абв-гд", третий - "абвгд". наверное, придется еще одну таблицу "словарь" создать, где при добавлении путевки по найденному написанию имени водителя находится "настоящее", которое используется дальше. а если в словаре ничего не найдено, должна запускаться ручная операция добавления или новой записи в словарь (если это - еще одно Н-ное написание имени уже существующего водителя), или еще и создание новой записи о водителе.

о выборе субд. загрузил сегодня у оракла Oracle Database XE (11g). при установке предупредило, что понадобится ~600 мб на диске. но когда установилась, директорий получился чуть больше 2 гб : ).

но это еще не энд ов дэ стори: пошел юзать/осваивать их юзырьинтерфейс, оказалось, что создать схему я с могу только из командной строки. а если хочу "как люди", то должен еще установить их SQL Developer, зазипованная инсталляция которого более 400 мб. но я прежде чем деинсталлировать все-таки пойду чуть дальше: инсталлирую таки этого дэвэлопэра и поиграюсь. пока впечатление, что все очень громоздко, на каждый пук диск долго тарахтит, окошки переключаются меееееееедленно, хотя я еще ничего не создал. поглядим, может только запрягает долго?

SQL Develope

-----

Посмотри в сторону Devart Studio для оракла.

Пользуюсь - иногда проблемы, но у меня старые версии баз...

Да, занесение новых обьектов в БД должно происходить оператором осознано. В GUI форме должна быть возможность занести нового водителя или машины (кнопочка "Новая машина" или "Новый водитель"). Ещё бы сделал окошко подсказки, где показывались возможные варианты из БД, например при вводе фамилии водителя.Это помогло бы оператору лучще ориентироваться и не плодить лишние обьекты.

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

При выборе БД я бы обратил внимание на следующие пункты:

1) Обьём данных

2) С каким типом данных нужно будет работать

3) Доступ к БД (только локальный или черезь сеть)

4) Количество клиентов, которые работают с БД

5) Какие нагрузки(обьём запрашиваемых данных) будут на ДБ и есть ли пиковые нагрузки

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

7) Будет ли оплачивать клиент лиценции, если вы возьмёте коммерческую БД (не ударит ли это по стоимости продукта)

8) Удобство и простота администрирования

Успехов

я и есть и заказчик, и исполнитель в этом проекте : (

Попал на конфренцию, так там пользование доскер так объясняли

пошел юзать/осваивать их юзырьинтерфейс

Ой, только не окошки Оракла.

Сколько пользователей то будет одновременно?

Чёт я понял что один. Слишком уж большой прицеп прийдётся тащить к Ораклу. Или хранимые процедуры требуются?

:-D

я и есть и заказчик, и исполнитель в этом проекте : (

Идеальный вариант. Руки не связаны, только творить. :-)

задалбываюсь с SQL Developer. все их самые актуальные доки ссылаются на версии 2 и 3, а у меня скачалась 17. естественно, все организовано уже не так, найти ничего невомзможно, пользуясь их доками. дубовейшая вещь! не понимаю, как такая огромная компания, у которй немало ресурсов (я думаю), может такой неудобный продукт создать? тема, понимаю, сложная. но у меня уже палец на мыши дергаться от боли начинает. создаем новую колонку - она сразу создается с дефолтным идиотским именем колэмХ и типом варкар 20. т.е. если мы создаем несколько однотипных колонок тима намбэр, например, нам нужно каждый раз клацнуть на имя, оно при этом не выбирается, только фокус поле получает, мы сами должны это выбрать и переписать. затем выбрать желаемый тип из комбобокса типов. далее. час искал, как добавить рилэйшн на соседнюю таблицу. описанное в их туториалах не подходит - у меня нет этих контролов. интуитивно клацаю правой мышкой на колонку, оно предлагает все что угодно, кроме этого. наклацал (случайно! мне в голову не пришло такое, они могли еще выше - в схему это вынести : ), что единственный способ (может есть еще, но не видно) - клацнуть правой мышкой на ТАБЛИЦУ, откроется меню с предложением constraint->add foreign key, где прийдется имя колонки выбирать, что отпало бы, будь этот пункт сразу в меню колонки. кстати, если выбрать "редактировать таблицу" (клацнуть на иконку карандашика), то там тоже есть слева на выбор "constraints", который если выбрать, то видно созданные чужие ключи. но создать такой же отсюда - невозможно. в общем, додавлю эти несколько таблиц таки, затем попробую связаться из приложения с этой базой и что-нибудь с ней поделать. это просто потому что жаль уже потраченного времени, но в качестве решения, конечно, эту субд для моей цели применять не стану, что-нибудь попроще выберу, или останусь на том, что есть. не так удобно, но я скорее себе эти удобства сам за пару вечеров сделаю, чем осваивать дубовых монстров.

дело в том, что когда на заказ, есть сроки, ресурсы, и это "помогает принимать решения", т.к. продукт когда-то должен быть готов. и есть заказчик, который должен ответить на вопрос: тебе белыйверх/чорныйниз или наоборот. а когда сам для себя - можно творить вечно, проверить массу креативных идей, но в результате все просто надоест раньше, чем появится то, чем можно пользоваться : )

я, конечно, додавлю эту затею, слишком многообещающе выглядит (на данном этапе).

задалбываюсь с SQL Developer.

Я правда уже успел забыть в каких случаях им пользовались, но оочень редко

А вот без Тоад-а и дня не обходилось

https://www.quest.com/products/toad-for-oracle/

хотя он дороговат.

Для NETa хорошо попробовать Devart

https://www.devart.com/dotconnect/oracle/

https://www.devart.com/entitydeveloper/

А это не то? 17.3 вроде

http://www.oracle.com/technetwork/developer-tools/datamode...

http://www.oracle.com/technetwork/developer-tools/sql-deve...

А это не то? 17.3 вродеhttp://www.oracle.com/technetwork/developer-tools/sql-deve...

ну да, именно "вроде" : ) идем по ссылочке, видим рилиз нотз на 17 и ссылочку на доку:

http://www.oracle.com/technetwork/database/enterprise-edit...

идем туда и видим то что там есть : (

именно на это попадаем, если в эскуэл дэвэлопере 17. кликаем на "помощь". если бы у них были доки поновее, они бы и сцылочку подправить не забылы : )

в общем, я от этого баловства пока ухожу, попробую пару вечеров поконструировать нечто вокруг Sytem.Data.DataSet и иже с ним. собственно, этим классом ограничивается мой практический опыт работы с базами данных. не считая пару раз построение соединения и конструирование запроса по образу и подобию уже имеющихся в приложении (уже даже не помню что за проект был).

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

Хм, а у меня не получается туда попасть

Вначале сюда,

https://docs.oracle.com/database/sql-developer-17.3/

а после сюда

https://docs.oracle.com/database/sql-developer-17.3/RPTUG/...

ну да ладно.

Если кинешь структуру базы я тебе для Sqlite базу и приложение с Linq сделаю, только должно быть не более 10 таблиц, иначе бесплатная версия не потянет.

спасибо. приложение с линк - это то, что у меня уже есть.

по вашей ссылке:

After you have entered the last column (transaction_type), check Advanced (next to Schema). This displays a pane for selecting more table options. For this table, you will use the Column Sequences and Foreign Keys panes.

в моей версии (17) НЕТУТКИ никакого "Advanced (next to Schema)". это раверняка - артефакты из версии 2.

Если кинешь структуру базы я тебе для Sqlite базу и приложение с Linq сделаю,

а вам это нафига? время девать некуда? эх, молодость, молодость ... будь я молодым, уделял бы больше времени книгам и спорту. сегодня спорту - экстрем, но максимально сжато по времени, чтиво - 99% техническое : (

а вам это нафига?

сложно сразу объяснить. Как минимум, если человек помог мне, то как бы грех не помочь и ему.

Тем более к базам я не равнодушен.

я вам пока ничем не помог. но спасибо в любом случае : )

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

А ведь без вашего толчка я бы не стал возится с WPF и потратил бы еще фиг знает сколько времени на решение проблемы с кнопкой.

Так что помощь была, хотя в общем то явного запроса с моей стороны не было.

я вам пока ничем не помог.

-----

Это кажется.

Участвуя в обсуждении, даже если высказываемое является полной глупостью,

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

Часто - именно этого бывает достаточно...

Я ваще уже давно пользуюсь встроенным в IntelliJ и забыл девелопера как страшный сон.

посмотрел. интересно: разработчики считают, что с/с++ пора списывать, или просто у них особая ориентация?

заморочка возникла. что считается хорошим стилем: одна база со множеством таблиц, если "темы схожие", или все-таки как-то выделить направления и создать более структурированный "набор баз данных"? с одной стороны, субд следят за тем, чтобы база была consistent, я так понимаю, что каждая база будет "правильная" поотдельности, а за совокупной правильностью нужно следить "самостоятельно"?

можно ли создавать средствами субд реляции между отдальными базами данных? например, имеются разные, но сходные базы. например, в нашем "транспортном цехе" (может, выслушать его начальника? : ) имеется не только база с путевками, но и база, ориентированная на выплату зарплаты (больше ничего в голову не приходит). или это должна быть одна база, потому что логично иметь одну таблицу сотрудников, из них некоторые могут быть водителями?

полная каша в голове : (

одна база со множеством таблиц, если "темы схожие", или все-таки как-то выделить направления и создать более структурированный "набор баз данных"?

-----

База - одна на одну задачу.

Если задачи связанные - то это одна задача.

Но обычно задают другой вопрос - если сущности похожи, но нужно ли заводить отдельную таблицу?

Ответ нас него прост - либо таблицу на каждую сущность, либо общий список сущностей и одна таблица с дополнительным ключем...

До 10-ка сущностей Я бы делал отдельные таблицы, больше - делал бы две таблицы.

можно ли создавать средствами субд реляции между отдальными базами данных?

-----

Давно хочу, но пока таких не видел.

Но не путай это с сегментацией файлов данных.

полная каша в голове : (

------

Это еще только начало... через годик - начнет побаливать...

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

Ее разделение на части повлечет за собой ручное писательство проверок и поддержки интегрированности.

полная каша в голове

не переживайте - это всегда так.

Процесс разработки структуры БД ничем не проще создания ПО.

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

Сорри, если уже читали

https://habrahabr.ru/post/254773/

http://i-novice.net/6-normalnyx-form-bd/

https://support.microsoft.com/ru-ru/help/283878/descriptio...

потому что логично иметь одну таблицу сотрудников

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

можно ли создавать средствами субд реляции между отдальными базами данных?

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

спасибо, вы мне все очень помогли. утешили в любом случае : )

новая заморочка. допустим, мы проектируем нечто в каком-то домене from scratch, но пока не все знаем: опыт показет. мы хотим иметь базу данных (или нечто, на ее базе построенное), и не знаем пока, сколько и каких приложений. одни приложения будут заниматься поддержанием базы данных в актуальном состоянии, другие будут эти данные для чего-то использовать, третьи - делать и то, и другое.

понятно, нужно как-то продумать структуру базы, но как мы должны строить приложение? должно ли оно знать эту структуру? напрашивается некий адаптер, который знает структуру и имеет интерфейс, отвечающий запросам приложения. кто как делает? в приложениях вы пишете FROM ... SELECT ..., или create_new_lorry (...), get_driver_age (...) и т.д.?

но как мы должны строить приложение? должно ли оно знать эту структуру?

-----

Многоуровнево. С базой будет работать DAL-уровень - он и будет "знать" структуру базы...

кто как делает?

-----

Поковыряй Entity Framework или другой ОРМ...

Хотя... при малом объеме - можно хоть а-ля-ВБ6 лепить - контролы с SQL в форме...

Проще наверное сказать, как лучше НЕ делать - Не размазывать доступ к элементам базы по всему приложению.

А так, довольно удобно Linq2SQL и использование POCO объектов для таблиц.

            int countDevices = (from row in _db.DeviceSensors where row.Id == dataItem.DeviceId select row).Count();

        public IQueryable<DeviceSensor> GetDeviceSensors()
        {
            IQueryable<DeviceSensor> query = from row in _db.DeviceSensors select row;
            return query;
        }

Но это если экстрима нет.

А то вот была база с таблицами, где более миллиона записей, там пришлось все Linq запросы снести и делать "метровые" SQL (это если печатать)

У них есть CLion.

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

Вообще, после продуктов JetBrains все эти эклипсы и вижуалстудии хочется забыть как страшный сон.

если вам дотнет приложение создать нужно (и наверное, любое под виндоуз), лучше визуал студии вам не найти.

Я не работаю с дотнетом, но имею основания предполагать, что вот это будет получше: https://www.jetbrains.com/rider/

Попробуйте ради интереса, интересно ваше мнение.

спасибо! попробую обязательно, как только разгребусь с "маленьким тулом вокруг System.Data.DataSet". он задал непростую загадку. тул работает уже довольно устрйчиво, баги 100% имеются, но уже с его помощью могу наваять схему базы данных. столкнулся с такой проблемой в этом классе. посоздавав бажу, таблицы, колонки, решил, что неплохо бы подобавлять рилэйшнз. допускаются множественные, но мне пока не надо, решил не усложнять, ограничиться только одинарными. но, как тулу положено, допускает ошибки и их исправления. по простоте душевной решил, что если добавил DataRelation, а потом удалил - проблема исчерпана. но не тут-то біло! когда создается рилэйшн, в участвующих таблицах, оказывается, сохраняются созданные при добавления ришэйшна Constraints! в общем, все работает красиво, но только пока мы заранее знаем, какие рилэйшнз нам нужны, и только их и создаем.

видимо, в дизайне ошибся, думал, буду крутиться вокруг реального объекта DataSet, и по ходу редактирования в гуи буду сразу отображать в нем изменения, и сохранять немедленно. оказывается, этот подход ввиду сложности объекта не годится: с базами, таблицами и колонками никаких проблем, пока не дошел до рилэйшнз, которые "чисто удалить" сам класс не позволяет. видимо, нужно какую-то теневую структуру создавать, редактировать и сохранять. и только когда она готова, нажатием на кнопочку можем создать (без ошибок и исправлений!) уже настоящий объект DataSet, и сохранить. только вот вопрос теперь: может оказаться так, что когда все это заработает, мне этот DataSet нафер не нужен будет, возможно, я лучше обойдусь моим созданным теневым объектом? : )

оказывается, этот подход

-----

Тебе говорилось - это не база...

хотел попробовать, но у них нет кастрированного варианта (типа "экспресс"), а только на месяц, с регистрацией и прочими штучками. мне это для попробовать слишком umstaendig.

Пыхх... Даешь левый мыл и ставишь на виртуалку...

...опробываешь по-быстрому, пишешь отчет, готово!...

человеку, думаю, интересно мнение, на чем-то основанное, а не лишь бы "а я и это знаю! а я и тут - экзперд!".

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