Működő MySQL Workbench alternatíva

Adatbázis: SQL, XML DB

Üdv mindenkinek ezen a meleg szombaton!

Ahogy a címben is írtam, olyan Workbench alternatívát keresek amely képességeiben vele összemérhető, csak ezzel a használhatatlan vacakkal ellentétben működik is. Már átfutottam ezt a szálat, de gondoltam inkább nyitok egy frissebbet.

DB tervezéshez és lekérdezések szerkesztéséhez kellene az új eszköz. Nem baj, ha nem FOSS, az sem baj ha fizetni kell érte, amíg hajlandó működni, és értelmes az ár (néhány 10 euró).

Előre is köszönök minden tippet!

Egyébként ez volt az a bug, ami után eldöntöttem, hogy képtelen vagyok tovább együtt élni ezzel a vacakkal.

  • 3296 megtekintés

Nagyon jól néz ki, csak kicsit drága ahhoz mérten hogy saját, nem kommerciális felhasználásra kellene jelenleg. De azért köszönöm a tippet, lehet hogy kipróbálom.

Igazából elsősorban iskolai és hobbiprojektekhez kellene egy új eszköz. Mint írtam, nem gáz ha fizetős, de ez nekem kicsit sok.

( vilmos.nagy | 2015. 07. 18., szo – 18:24 )

DbSchema

Inkább tervezéshez, mint adminisztrációhoz, de ingyen kipróbálható, szerintem 5 percet megér.

--
blogom

( vl v | 2015. 08. 15., szo – 03:46 )

Egyébként ez volt az a bug, ami után eldöntöttem, hogy képtelen vagyok tovább együtt élni ezzel a vacakkal.

Komolyan, tényleg az a bajod, hogy mindenféle fos karaktert raksz a könyvtárnevekbe, és ezen programok hasraesnek? Üdvözöllek az informatika világában! Ha nem akarod szopatni magadat, akkor CSAK a következő karaktereket használod könyvtár- és fájlnevekben:

- a-z US ASCII abc betűi
- 0-9
- kötőjel (-)
- aláhúzás (_)
- pont (.)

A következő karakterekkel pedig véletlenül SEM szopatod magadat:
- bármilyen, nem US ASCII abc szerinti betű (ékezetes és egyéb random izék)
- space ( )
- perjel (/) ill. backslash (\) - nyilván a kettőből az egyiket a OS meg sem engedi, de a másikat akkor sem használjuk, ha véletlenül megengedné
- aposztróf (')
- idézőjel (")
- backtick (`)
- and (&)
- pontosvessző (;)
- pipe (|)
- csillag (*)
- kérdőjel (?)
- dollárjel ($)
- százalékjel (%)
- felkiáltójel (!)

A 80-as/90-es évek telefonált és kéri vissza az elnevezési módszertanát ;)
De komolyan, 2015-ben még mindig itt tartunk? (igen, tudom, hogy vannak programok/protokollok, amik ugranak erre, azoknál érdemes figyelni, de akkor is).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ne vicceljünk, a Windowsban pl. még most is ott van az a Win32 file system API, ami nem UTF-kompatibilis (értsd: 8-bites, codepage-based), amit nyilván programok használnak is. Ha nem jól állítod be ezt a codepage-et, vagy netalántán nem is létezik jó beállítás (nincs olyan codepage, ami minden karaktert lefed a nevekben), akkor "Így Jártál(tm)", a nem konvertálható nevű fájlokat ezek a programok nem fogják tudni kezelni...

És akkor csak azért, mert vannak legacy cuccok, hagyjunk minden változást a francba, és soha ne változzon semmi? A nem Unicode-képes programokat ki kell dobni, oszt jónapot.

A másik, amitől frászt kapok, teljes magyar billentyűzet, magyar billentyűzetkiosztás, és ékezet nélkül ír e-mailt, mert "lehet, hogy a fogadó fél régi klienst használ". Ha a fogadó fél régi klienst használ, akkor frissítsen, van belőle bőven választék, én pl. szeretek full-text keresni levelekben, amin nem segít, ha valaki teljesen ekezet nelkul ir. De ugyanígy mondhatom azt, akit régen egy "informatikus ismerőse" megtanított, hogy érdemes mindent az [0-9A-Z_]+ karakterkészletből elnevezni (ARVIZTURO_TUKORFUROGEP), mert azzal nem lehet baj (*), cserébe legalább taxonomy-freak, úgyhogy 5-10 szinten tartott mappákban több száz karakteres teljes path-ekkel dolgozik. Gyönyörűen tud kinézni egy C:\Users\vezetek.keresztnev\Documents\MUNKAHELYI\PROJEKTEK\[PROJEKT_AZONOSITO]\PROJEKT_DOKUMENTACIO\KORABBI_VERZIOK\2015\08\PROJEKT_DOKUMENTACIO.docx fájl.

(*): Még szerencse, hogy legalább DOS-t nem látott soha, akkor még 8 karakterre is limitálná magát...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

És akkor csak azért, mert vannak legacy cuccok, hagyjunk minden változást a francba, és soha ne változzon semmi? A nem Unicode-képes programokat ki kell dobni, oszt jónapot.

Öööö... de szegény paraszt honnét tudja, hogy melyik ilyen, és mit kéne kidobni? Az a baj, hogy nincs ilyen funkció egyesek "kedvenc" oprendszerében, ami megmutatná, hogy ez és ez a program elavult API-t használ. Vagy nem lehet ki-bekapcsolni, hogy legyen-e ilyen API (és akkor tényleg hamar kiderülne, hogy ki a hunyó).

De Linuxon is probléma, hogy egyes programok annyira komolyan veszik pl. a locale beállításokat, hogy a locale szerint nem megjeleníthető nevű fájlt nem hajlandó megnyitni.

Az ember azért használ ékezet nélküli levelet, mert nem akar ékezeteket írni. Vagy mert túl nagy szopás. Pl. idegen billentyűzeten a faszomnak van kedve állandóan váltogatni a magyar és az angol kiosztás között (angolon ugye nincs ékezetes betű, magyaron meg minden más szar helyen van, az y-z problémakörről nem is beszélve, azért külön kijárna a németeknek egy bunkósbot), mondaton belül akár többször is. Nyilván a saját gépemen megoldom, hogy egyszerre legyenek jó helyen az egyéb karakterek, és tudjanak lenni magyar ékezetek. De ez pl. Windowson nem is tudom, hogy megoldható-e (custom kiosztás használata).

Az ember azért használ ékezet nélküli levelet, mert nem akar ékezeteket írni.

A technológiai dolgokat direkt írtam (magyar billentyűzet és kiosztás). Ha valakinek nincs éppen magyar bill a kezében, nem gépel vakon, akármi, megértő vagyok. Ha mobilról írogat, és úgy nem használ ékezetet, mert bár tudna, de lényegesen lassabb ékezettel írni, megértem.

De arra hivatkozni, hogy mi van, ha a túloldal csak ascii-t tud (és ezt az UTF-8 tényleg szépen megoldja, ezt elismerem), az nekem sok.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Elolvastam a bugot, itt szerintem többről van szó. Az a kisebb gond, hogy nem kezeli a speciális karaktereket (miközben manapság már kb. minden programnyelvhez van library, ami kezeli, beolvassa, darabolja, stb. az elérési utakat). A nagyobb baj az, hogy egy bug miatt nem csak nem menti az új fájlt, de törli is a régit. Ha egy program ilyet csinál, akkor valószínűleg évekig a közelébe se néznék, még ha a konkrét hibát ki is javítják. Mert ez azt sejteti, hogy nem eléggé hozzáértő emberek írták, és éles célra nem egy életbiztosítás a használata.

--

( hawk | 2015. 08. 18., k – 16:17 )

Ez most komoly?..... NEMÁÁÁÁ.
Azért elég trééé, hogy rendszergazda, programozó létére bárki ékezetes
roszabb esetben speciális karaktereket akar belerakni fájl, eljárás, változó nevébe.

ui: Törném el mindkét kezén egyesével az újperceit neki....
Mondom mindezt azok után, hogy nemrégien egy cseh nyelven
íródott pénzügyi XML-hez kellett XSL-t írnom, ahol az összes
tag cseh nyelvű volt és még speckó karakterek is benne voltak.
Ja és az adatbázis táblák, mezők is cseh nyelvűek.
2015-ben egy nemzetközi szoftvert így elkészíteni és kiadni. Sértés!

"Azért elég trééé, hogy rendszergazda, programozó létére bárki ékezetes
roszabb esetben speciális karaktereket akar belerakni fájl, eljárás, változó nevébe."

Lel. Erre csak ennyit tudok mondani:

public class ÁrvíztűrőTükörfúrógép {}

Egyébként miután egyetlen egy karakter sem speciális, egészen addig, ameddig az emberek nem ruházzák fel valami speciális jelentéssel, szimplán trehányság és lustaság kérdése az, hogy mennek-e azok a hú de speciális karakterek és/vagy ékezetes betűk mindenhol. A szánalmas az, ha valahol nem mennek 2015-ben.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ez most komoly?..... NEMÁÁÁÁ.
Azért elég trééé, hogy rendszergazda, programozó létére bárki ékezetes
roszabb esetben speciális karaktereket akar belerakni fájl, eljárás, változó nevébe.

Az a helyzet, hogy a keresztnevem ékezetes karaktert tartalmaz, és nem fogok nevet váltani pár fejlesztő miatt akik képtelenek haladni a korral. Inkább lecserélem a szoftvert. (Amúgy nem magával a fájlnévvel volt gond, hanem az elérési úttal: C:\Users\...)